From owner-atom-syntax@mail.imc.org Sun Aug 1 08:39:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18299 for ; Sun, 1 Aug 2004 08:39:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71CNgAL050874; Sun, 1 Aug 2004 05:23:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71CNgxt050873; Sun, 1 Aug 2004 05:23:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71CNfkp050867 for ; Sun, 1 Aug 2004 05:23:42 -0700 (PDT) (envelope-from distobj@acm.org) Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1BrFOB-00016b-00 for ; Sun, 01 Aug 2004 08:24:31 -0400 Date: Sun, 1 Aug 2004 08:24:31 -0400 To: Atom Syntax Subject: Re: Identity conundrum Message-ID: <20040801122431.GR30868@markbaker.ca> References: <87fz79xt9u.fsf@nwalsh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fz79xt9u.fsf@nwalsh.com> User-Agent: Mutt/1.3.28i From: Mark Baker Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jul 30, 2004 at 02:08:13PM -0400, Norman Walsh wrote: > One idea of identity is that entries have immutable identity. That is, > an atom:id identifies an atom:entry that cannot change. [snip] > Another view of identity is that entries are snapshots of an > abstraction that has identity. I'd just like to point out that the former is a special case of the latter, where a particular instance of an entry is the "abstraction that has identity". I believe we should support the more general model. Mark. From owner-atom-syntax@mail.imc.org Sun Aug 1 12:07:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08362 for ; Sun, 1 Aug 2004 12:07:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71FrKw7060812; Sun, 1 Aug 2004 08:53:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71FrK8S060811; Sun, 1 Aug 2004 08:53:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71FrJ3Y060805 for ; Sun, 1 Aug 2004 08:53:20 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from cpc1-stke1-5-0-cust6.bagu.cable.ntl.com ([81.97.134.6]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040801155326.UANY3857.mta07-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com> for ; Sun, 1 Aug 2004 16:53:26 +0100 Date: Sun, 1 Aug 2004 16:53:08 +0100 From: David Powell X-Mailer: The Bat! (v2.12 RC/4) Business Reply-To: David Powell X-Priority: 3 (Normal) Message-ID: <1414385297.20040801165308@djpowell.net> To: Atom-Syntax Subject: PaceUriReferences MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have created a proposal to replace the use of the term "URI" with the term "URI reference" in various places in atom-format, and also to require atom:id to be an absolute URI reference. http://www.intertwingly.net/wiki/pie/PaceUriReferences == Abstract == Replace the term "URI" with the term "URI reference". State that atom:id elements cannot contain relative URI references. This proposal is based on the text of http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt together with the changes proposed by PaceXmlBaseEverywhere == Status == Open == Rationale == Where the format specification currently uses the term "URI", in many cases it should be using the term "URI reference" in order to allow relative URIs to be used in Atom. The use of relative URI references has already been implied by the use of XML Base in Atom. The use of relative URI references in atom:id creates extra complexity with comparatively little benefit however, so this Pace also proposes that atom:id should only contain absolute URI references. One of the concerns is that if relative URI references are used in ids, then this could cause entries to have multiple aliases if the feed can be accessed from multiple locations, which is a property that Atom disallows. Because it is common for fragments to be used in identifiers, especially in RDF, this Pace proposes that atom:id should be an absolute URI reference, rather than an absoluteURI. This proposal only replaces the term "URI" with "URI reference" when it is used to refer to a syntactic component in the specification, the term URI is retained when it is used to refer to the meaning of the URI that the reference ultimately refers to. == Proposal == In section 3.2.2 replace: The content of atom:uri in a Person construct MUST be a URI [RFC2396]. with: The content of atom:uri in a Person construct MUST be a URI reference [RFC2396]. In section 3.4.2 replace: it MAY be used as a hint to determine the type of the representation which should be returned when the URI in the href attribute is dereferenced. with: it MAY be used as a hint to determine the type of the representation which should be returned when the URI conveyed by the href attribute is dereferenced. In section 3.4.3 replace: The "href" attribute contains the link's URI. Link constructs MUST have a href attribute, whose value MUST be a URI [RFC2396]. with: The "href" attribute conveys the link's URI. Link constructs MUST have a href attribute, whose value MUST be a URI reference [RFC2396]. In section 4.2.6 replace: The content of this element, when present, MUST be a URI. with The content of this element, when present, MUST be a URI reference [RFC2396]. This URI reference MUST be absolute, and MAY contain a fragment identifier. absolute-URI-reference = absoluteURI [ "#" fragment ] In section 4.2.7 replace: The atom:generator element MAY have a "uri" attribute whose value MUST be a URI. When dereferenced, that URI SHOULD produce a representation that is relevant to that agent. with The atom:generator element MAY have a "uri" attribute whose value MUST be a URI reference [RFC2396]. When dereferenced, the URI SHOULD produce a representation that is relevant to that agent. In section 5.5 replace: The content of this element MUST be a URI. with The content of this element MUST be a URI reference [RFC2396]. This URI reference MUST be absolute, and MAY contain a fragment identifier. absolute-URI-reference = absoluteURI [ "#" fragment ] In section 5.12 replace: The content of this element MUST be a URI. with The content of this element MUST be a URI reference [RFC2396]. == Impacts == This proposal only addresses the usage of relative relative URI references in Atom Format. The use of relative URI references in Atom Publishing Protocol is more complex and may need to be addressed separately. Unfortunately there is no term explicitly defined in RFC2396 for an absoluteURI with optional fragment so the absolute-URI-reference construct has to be created. However RFC2396bis does define the term "URI" to fit this need, so if RFC2396bis is accepted for use in Atom, then the definition of absolute-URI-reference can be removed and its usage replaced with the term "URI". Additionally, if Atom chooses to use IRIs instead of URIs, then that proposal must replace the usage of "URI" and "URI reference" with "IRI" and "IRI reference". == Notes == See also: PaceXmlBaseEverywhere PaceIri PaceUriOrItsSuccessor -- Dave From owner-atom-syntax@mail.imc.org Sun Aug 1 12:20:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08924 for ; Sun, 1 Aug 2004 12:20:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71G6NU0061333; Sun, 1 Aug 2004 09:06:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71G6NXr061332; Sun, 1 Aug 2004 09:06:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71G6MtV061326 for ; Sun, 1 Aug 2004 09:06:22 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i71G4153020074 for ; Sun, 1 Aug 2004 10:04:01 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1R005H8ZEMAE@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 01 Aug 2004 10:06:23 -0600 (MDT) Received: from [130.129.132.230] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1R003KLZELL2@mail.sun.net> for atom-syntax@imc.org; Sun, 01 Aug 2004 10:06:22 -0600 (MDT) Date: Sun, 01 Aug 2004 08:24:08 -0700 From: Tim Bray Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) In-reply-to: <4.2.0.58.J.20040801083942.051f9a88@localhost> To: Martin Duerst Cc: Atom Syntax , Mark Pilgrim Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jul 31, 2004, at 5:34 PM, Martin Duerst wrote: >>> B) Some clients may perform all of these steps, but others may not, >>> and therefore some will treat these URIs as identical but others >>> won't. >> B, so producers SHOULD NOT produce variant spellings of the same URI. > > There will be > implementers that don't read the spec and will try to use this > equivalence, > in the same way there are probably implementers out there that try to > use case equivalence even when they are not supposed to. > > I could for example understand quite well that some spiders take > http://example.com/UPPER and http://example.com/upper to be equivalent, Martin, please react to what I actually said, not some fantasy exercise. What I said is that software implementations will do an unpredictable set of things, all *within* the spec. By the way, I have written two very large-scale web spiders that have processed in aggregate in excess of a billion URLs (and I wrote section 6 of 2396bis), so I'm not making this up. > Indeed, I do not > know any server or client that would behave according to B above. You do now. See Sam's recent posting, http://www.intertwingly.net/blog/2004/07/31/URI-Equivalence, which makes it obvious that two popular software implementations, C# and Java, which I guarantee will be used by lots of programmers to compare URIs, do URI manipulation inside their equals() method, each one differently. In fact, if you're a Java or C# programmer, you're going to have to do extra work to get codepoint rather than "smart" comparison. It is foolish for us to try to stop this. On the other hand, producers should not count on anything more. The following is actually consistent with software reality: Authors of software which compares URIs for equivalence SHOULD consider the discussion in RFC2396bis Section 6, and such software MAY use codepoint-for-codepoint comparison. Producers of URIs SHOULD NOT generate variant spellings of the same URI. If someone wants to argue for a MUST NOT in that last sentence, it's worth considering. -Tim From owner-atom-syntax@mail.imc.org Sun Aug 1 13:35:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12693 for ; Sun, 1 Aug 2004 13:35:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71HL7Kj066715; Sun, 1 Aug 2004 10:21:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71HL7QO066714; Sun, 1 Aug 2004 10:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id i71HL67E066703 for ; Sun, 1 Aug 2004 10:21:07 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 17923 messnum 7734059 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 1 Aug 2004 17:21:04 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail01.svc.cra.dublin.eircom.net (qp 17923) with SMTP; 1 Aug 2004 17:21:04 -0000 Message-ID: <410D267C.6040002@dehora.net> Date: Sun, 01 Aug 2004 18:21:00 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Tim Bray CC: Martin Duerst , Atom Syntax , Mark Pilgrim Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > [...reality...] > > Authors of software which compares URIs for equivalence SHOULD consider > the > discussion in RFC2396bis Section 6, and such software MAY use > codepoint-for-codepoint comparison. Producers of URIs SHOULD NOT generate > variant spellings of the same URI. > > If someone wants to argue for a MUST NOT in that last sentence, it's > worth considering. I don't get it. What's the purpose of saying anything here unless there is sufficient specification to interoperate with? Whatever about reality-as-engineered, if the identity functions, invariants and whatnot are *clearly defined* it will be at least apparent what obligations producers and consumers are under. So we can file bug reports or contribute fixes and stuff. cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 1 14:16:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14336 for ; Sun, 1 Aug 2004 14:16:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71I3hlK069327; Sun, 1 Aug 2004 11:03:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71I3huK069326; Sun, 1 Aug 2004 11:03:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71I3ggZ069320 for ; Sun, 1 Aug 2004 11:03:42 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i71I4t2u002525; Sun, 1 Aug 2004 14:04:58 -0400 Message-ID: <410D307B.9060101@intertwingly.net> Date: Sun, 01 Aug 2004 14:03:39 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > The following is actually consistent with software reality: > > Authors of software which compares URIs for equivalence SHOULD consider the > discussion in RFC2396bis Section 6, and such software MAY use > codepoint-for-codepoint comparison. Producers of URIs SHOULD NOT generate > variant spellings of the same URI. > > If someone wants to argue for a MUST NOT in that last sentence, it's > worth considering. I'll argue for something stronger. Different, but stronger. Let me start by enumerating some first principles: 1) The purpose of elements in atom is to enable efficient identity comparison. 2) Clients may use a variety of techniques for comparison varying from absolutely none to very aggressive normalization prior to comparison. 3) IDs will be transmitted by a variety of means including, but not limited to napkins, busses, and keynotes[1]. So, if we can't control how ids are consumed or transmitted, we control what we can: ids are recorded. We have the Atom specification require that all ids MUST be in a canonical form. We start with the rules in rfc 2396bis[2]. We add a few: URIs can't be relative. URIs must be utf-8, in fact must be NFC (or whatever form we select). For schemes which define an option port, we require that all ports be explicit (or alternately, we require any ports that match the default for the scheme chosen be omitted). What are the benefits? Interoperability without constraining how clients compare URIs. And the feedvalidator can provide early detection of potential problems before they are problems. And not insignificantly, requiring authors to actually think about how the define identity . This last part should not be minimized, given all the discussion about not allowing relative URIs and perhaps even constraining the scheme to exclude HTTP. What are the costs? Authors of sofware will have add code to normalize their URIs. Realistically, these costs will fall disproportionally on those who chose to use http URIs. But even there, the costs likely to be minimal, as it can be observed that most URIs in the wild already conform to the canonicalization rules of rfc2396bis: the scheme is lower case, the character set is mostly ASCII, escaping is only done when needed, etc. Finally, what happens if somebody ignores this requirement? Beyond error messages from the feedvalidator, things will tend to degrade gracefully. Identity comparisons will likely work anyway. And when they don't, and users complain to aggregator authors (let's face it, that's who will receive the bulk of these complaints), the authors can point to the spec and the feedvalidator as evidence that the problem is in the feed itself. Unless there is violent objection, I'll write up a Pace. - Sam Ruby [1] [2] From owner-atom-syntax@mail.imc.org Sun Aug 1 15:26:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18701 for ; Sun, 1 Aug 2004 15:26:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71JIVtH072262; Sun, 1 Aug 2004 12:18:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71JIV9w072261; Sun, 1 Aug 2004 12:18:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71JITqU072250 for ; Sun, 1 Aug 2004 12:18:30 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id A39297C0F3; Sun, 1 Aug 2004 22:13:17 +0200 (CEST) Date: Sun, 01 Aug 2004 21:22:22 +0200 To: "Norman Walsh" Subject: Re: Identity conundrum Cc: Atom-Syntax References: <87fz79xt9u.fsf@nwalsh.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <87fz79xt9u.fsf@nwalsh.com> User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 30 Jul 2004 14:08:13 -0400, Norman Walsh wrote: > It seems to me that we have conflicting ideas about what identity > means and that it might help to look directly at that issue, so here > goes. [...] Although I don't disagree with your conceptions, I have another set of terms and ideas attached to them: «Dynamic resource» or «Streaming resource» This is a resource that is dynamically updated by either new revisions or modifications to the same subject (aka story), or by representing many different resources about the same type of subject. Examples of dynamic resources is the front page of a web site, an RSS or Atom feed, chaning (aka non-stable) RSS or Atom entries and a web page or Atom entry representing «Tomorrow's weather reports». «Static (aka stable) resource» This is a resource that is created and issued only once, and will never change to give or have another meaning. It will always be about one single subject, and the view on that subject will always be the same, whenever you retrieve the resource. Examples of static resources is revisioned Atom entries, the individual versions of a given specification, or any other resource that is issued only once. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 1 16:41:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23490 for ; Sun, 1 Aug 2004 16:41:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71KY9Vs077202; Sun, 1 Aug 2004 13:34:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71KY91e077201; Sun, 1 Aug 2004 13:34:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71KY8eb077195 for ; Sun, 1 Aug 2004 13:34:09 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so181188rnk for ; Sun, 01 Aug 2004 13:34:11 -0700 (PDT) Received: by 10.38.2.74 with SMTP id 74mr85927rnb; Sun, 01 Aug 2004 13:34:10 -0700 (PDT) Message-ID: <3f1451f504080113344193af88@mail.gmail.com> Date: Sun, 1 Aug 2004 16:34:10 -0400 From: Joe Gregorio To: Sam Ruby Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Cc: Tim Bray , Atom Syntax In-Reply-To: <410D307B.9060101@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 01 Aug 2004 14:03:39 -0400, Sam Ruby wrote: > Unless there is violent objection, I'll write up a Pace. +1 -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Aug 1 17:19:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24682 for ; Sun, 1 Aug 2004 17:19:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71LCo7a078555; Sun, 1 Aug 2004 14:12:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71LCog4078554; Sun, 1 Aug 2004 14:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (open-dyn-e-130-129-135-247.ietf60.ietf.org [130.129.135.247] (may be forged)) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71LCl9I078546; Sun, 1 Aug 2004 14:12:48 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <410D307B.9060101@intertwingly.net> References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> Date: Sun, 1 Aug 2004 14:12:54 -0700 To: Sam Ruby , Tim Bray From: Paul Hoffman / IMC Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Cc: Atom Syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:03 PM -0400 8/1/04, Sam Ruby wrote: >3) IDs will be transmitted by a variety of means including, but not > limited to napkins, busses, and keynotes[1]. Say what? Why on earth would I write a feed ID or an entry ID anywhere? >Unless there is violent objection, I'll write up a Pace. I non-violently object because I don't understand one of the pillars of your proposal. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Aug 1 18:15:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27942 for ; Sun, 1 Aug 2004 18:15:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71M79Cf081418; Sun, 1 Aug 2004 15:07:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i71M79is081417; Sun, 1 Aug 2004 15:07:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i71M78rO081404; Sun, 1 Aug 2004 15:07:08 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i71M8Qlf013138; Sun, 1 Aug 2004 18:08:28 -0400 Message-ID: <410D698E.6080702@intertwingly.net> Date: Sun, 01 Aug 2004 18:07:10 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Tim Bray , Atom Syntax Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > At 2:03 PM -0400 8/1/04, Sam Ruby wrote: > >> 3) IDs will be transmitted by a variety of means including, but not >> limited to napkins, busses, and keynotes[1]. > > Say what? Why on earth would I write a feed ID or an entry ID anywhere? > >> Unless there is violent objection, I'll write up a Pace. > > I non-violently object because I don't understand one of the pillars of > your proposal. In the immortal words of an author of two very large-scale web spiders that have processed in aggregate in excess of a billion URLs[2], contributor to rfc 2396bis[3], and co-chair of this working group[4], "shit happens"[5]. Also, note that the napkins, busses, and keynotes comment was derived from another comment by Tim Bray[1]. On the topic of ids, it seems that comparision is the key operation. My first preference would have been to define the rules precisely. One such set of rules would be those defined by Namespaces in XML 1.1[6] which are entirely unambiguous. However, given Tim's strong opinions on the subject, it appears likely that such a proposal would not achieve consensus. So, given this reality - and in the interest of interoperability - if we can't constrain how ids are compared, I would like to constrain how ids are expressed. Simply put, if people are permitted to use the .Net Uri.Equals or the Java URI.equals methods to determine atom:id equivalence, I want to make sure that they don't ever treat two distinct URIs as equivalent. Looking at the rfc 2396bis rules, they seem very reasonable and natural. In fact, none of the URI's listed after my signature would violate any of them. - Sam Ruby [1] [2] [3] [4] [5] [6] From owner-atom-syntax@mail.imc.org Mon Aug 2 06:04:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26900 for ; Mon, 2 Aug 2004 06:04:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i729tv7L028293; Mon, 2 Aug 2004 02:55:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i729tvYG028292; Mon, 2 Aug 2004 02:55:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.afp.com (smtp2.afp.com [158.50.208.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i729ttpp028247 for ; Mon, 2 Aug 2004 02:55:56 -0700 (PDT) (envelope-from laurent.lemeur@afp.com) Received: from alox.afp.com (unknown [158.50.165.141]) by smtp2.afp.com (Sendmail) with ESMTP id C52F046407 for ; Mon, 2 Aug 2004 11:55:48 +0200 (CEST) Received: from sdtc05 (sdtc05.afp.local [158.50.180.103]) by alox.afp.com (8.12.9/8.12.9) with ESMTP id i729tkt6020517 for ; Mon, 2 Aug 2004 11:55:46 +0200 (METDST) From: "Laurent Le Meur" To: "'Atom-Syntax'" Subject: RE : Identity conundrum ... and links Date: Mon, 2 Aug 2004 11:55:48 +0200 Message-ID: <005a01c47876$e3a40db0$67b4329e@afp.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i729tupp028285 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The unique identity of an entry is particularly useful in two situations: 1/ asserting that two entries at different location, and maybe in a different physical form, convey the same meaning (i.e are exactly the same or are snapshots of the same abstraction), and so avoiding duplicates. 2/ being able to link unambiguously and in a permanent way an entry to another entry. Let's imagine a comment about an opinion. If the author of the opinion changes his mind after the comment is published, and updates his entry without any change of identification, the comment will become totally out of sync with the linked entry. If the update of an entry is really significant (if its meaning/semantics has changed) then can it still really be the same entry? I suggest that it should rather be a new entry *derived from* (or superceding as in [1] if I understand correctly) the previous one. Is it something worth mentioning in the 4.2.6 ("atom:id" Element) paragraph? On the other side a/ for metadata modification or content corrections, which do not imply a change of meaning of the content and b/ for dynamic resources [2] like the front page of a web site or the TOC of a document, links to the entry don't risk being semantically broken. It may then be useful to put a revision mechanism in place and be able to link to a certain revision of the entry but it is not required (the NewsML and LSID URI schemes support revisions but many URI schemes don't). Note: the debate on "update date-time" is related to this notion of identity of an item and significant changes; given the moratorium on dates, I won't comment on this part now. [1] http://www.imc.org/atom-syntax/mail-archive/msg08200.html [2] http://www.imc.org/atom-syntax/mail-archive/msg08216.html Laurent Le Meur Agence France Presse > -----Message d'origine----- > De : owner-atom-syntax@mail.imc.org [mailto:owner-atom- > syntax@mail.imc.org] De la part de Asbjørn Ulsberg > Envoyé : dimanche 1 août 2004 21:22 > À : Norman Walsh > Cc : Atom-Syntax > Objet : Re: Identity conundrum > > > On Fri, 30 Jul 2004 14:08:13 -0400, Norman Walsh wrote: > > > It seems to me that we have conflicting ideas about what identity > > means and that it might help to look directly at that issue, so here > > goes. [...] > > Although I don't disagree with your conceptions, I have another set of > terms and ideas attached to them: > > «Dynamic resource» or «Streaming resource» > > This is a resource that is dynamically updated by either new > revisions or modifications to the same subject (aka story), > or by representing many different resources about the same > type of subject. > > Examples of dynamic resources is the front page of a web site, > an RSS or Atom feed, chaning (aka non-stable) RSS or Atom > entries and a web page or Atom entry representing «Tomorrow's > weather reports». > > «Static (aka stable) resource» > > This is a resource that is created and issued only once, and > will never change to give or have another meaning. It will > always be about one single subject, and the view on that > subject will always be the same, whenever you retrieve the > resource. > > Examples of static resources is revisioned Atom entries, the > individual versions of a given specification, or any other > resource that is issued only once. > > -- > Asbjørn Ulsberg -=|=- asbjornu@hotmail.com > «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Aug 2 06:17:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27366 for ; Mon, 2 Aug 2004 06:17:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72ABwHQ034555; Mon, 2 Aug 2004 03:11:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72ABwCF034554; Mon, 2 Aug 2004 03:11:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72ABvBB034495 for ; Mon, 2 Aug 2004 03:11:57 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 68EF07C0F3; Mon, 2 Aug 2004 13:06:36 +0200 (CEST) Date: Mon, 02 Aug 2004 12:15:49 +0200 To: "Ken MacLeod" Subject: Re: Identity conundrum References: Cc: Atom-Syntax From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 31 Jul 2004 12:12:13 -0500, Ken MacLeod wrote: > > > urn:myentry > urn:myentry:2 > Hello There > > > urn:myentry > urn:myentry:1 > Hello > > My take on this is that both views should be supported in atom:id. Since the simplest of the two views is the one that «flattens» all instances, e.g. the current view in blog tools, this view should be the one supported in Atom Core. The more advanced view can then be layered on top of the basic view as an extension. This can be achieved by telling consumers what profile a feed conforms to, and by reading the specification for that profile, you understand the semantics of the Atom elements, which will still reside in the core Atom namespace. Such a profile could for example re-define the semantics of atom:id and atom:issued from referring to the latest (or first) version of an entry, to «this instance». The rules for atom:id could also be changed into requiring a given ID scheme, or at least a scheme that supports versioning. For example: urn:myentry:2 Hello There urn:myentry:1 Hello This would still make the feed parsable by clients that don't understand the «versioning» profile, and the semantics won't be so off that the data is useless. Everything still works just fine, and a client that doesn't support the «versioning» profile will at the worst display a versioned entry over again, which is what the author would want to happen, anyway (re the 'Updated' element). What's great about this approach is that you can use the same core Atom elements to mean slightly different things in a given profile, and don't have to clutter the feed with extension namespaces when what you're doing is just refining Atom's core semantics. If you're really extending the format, the elements should of course reside in extension namespaces. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Aug 2 06:28:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27972 for ; Mon, 2 Aug 2004 06:28:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72AJ8jp037373; Mon, 2 Aug 2004 03:19:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72AJ8nk037371; Mon, 2 Aug 2004 03:19:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72AJ7ZO037329 for ; Mon, 2 Aug 2004 03:19:07 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id A27BF7C130; Mon, 2 Aug 2004 13:13:50 +0200 (CEST) Date: Mon, 02 Aug 2004 12:23:04 +0200 To: "David Orchard" , "Martin Duerst" Subject: Re: PaceBasicAtomID - maybe we're done Cc: Atom-Syntax References: <32D5845A745BFB429CBDBADA57CD41AF094A8052@ussjex01.amer.bea.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF094A8052@ussjex01.amer.bea.com> User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 30 Jul 2004 16:39:30 -0700, David Orchard wrote: > I don't understand this argument. An HTTP URI is owned by the domain > authority. It's as persistent as that authority decides. I'll repeat Mark Pilgrims comment to this: «You say that like it's a good thing». It's not. > It is not "by default transient". But do you agree that it's not persistent? If so, that's a problem big enough. > If an authority wants persistent HTTP URIs, then it should follow some > URI space scheme that does so, ie http://foo.com/uuid. That's one of > the great things about HTTP URIs. The domain authority can choose > which features it wants or doesn't want. But for atom:id authorities can't just «choose which features it wants or doesn't want». They need to support a set of requirements in their identities, and for tag, LSID and NewsML URN's, those requirements go with the scheme (at least to a certain extent). With HTTP URI's, those requirements aren't fulfilled to the least bit withohut thinking really hard about it. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Aug 2 08:14:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02370 for ; Mon, 2 Aug 2004 08:14:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72C0Ksv050492; Mon, 2 Aug 2004 05:00:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72C0K39050491; Mon, 2 Aug 2004 05:00:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72C0Jet050477 for ; Mon, 2 Aug 2004 05:00:20 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so97553rnl for ; Mon, 02 Aug 2004 05:00:21 -0700 (PDT) Received: by 10.38.181.17 with SMTP id d17mr182928rnf; Mon, 02 Aug 2004 05:00:21 -0700 (PDT) Message-ID: <3f1451f50408020500263fcf55@mail.gmail.com> Date: Mon, 2 Aug 2004 08:00:21 -0400 From: Joe Gregorio To: Sam Ruby Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Cc: Paul Hoffman / IMC , Tim Bray , Atom Syntax In-Reply-To: <410D698E.6080702@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410D698E.6080702@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 01 Aug 2004 18:07:10 -0400, Sam Ruby wrote: > On the topic of ids, it seems that comparision is the key operation. My > first preference would have been to define the rules precisely. One > such set of rules would be those defined by Namespaces in XML 1.1[6] > which are entirely unambiguous. However, given Tim's strong opinions on > the subject, it appears likely that such a proposal would not achieve > consensus. This is curious since my reading of the threads looks like there is rough concensus on Simple String Comparison for the atom:id. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Aug 2 08:51:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03870 for ; Mon, 2 Aug 2004 08:51:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72ChZ80053515; Mon, 2 Aug 2004 05:43:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72ChZjr053514; Mon, 2 Aug 2004 05:43:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72ChYM5053500; Mon, 2 Aug 2004 05:43:34 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i72CiqDm022648; Mon, 2 Aug 2004 08:44:52 -0400 Message-ID: <410E36F7.7010802@intertwingly.net> Date: Mon, 02 Aug 2004 08:43:35 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Paul Hoffman / IMC , Tim Bray , Atom Syntax Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410D698E.6080702@intertwingly.net> <3f1451f50408020500263fcf55@mail.gmail.com> In-Reply-To: <3f1451f50408020500263fcf55@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: > On Sun, 01 Aug 2004 18:07:10 -0400, Sam Ruby wrote: > >>On the topic of ids, it seems that comparision is the key operation. My >>first preference would have been to define the rules precisely. One >>such set of rules would be those defined by Namespaces in XML 1.1[6] >>which are entirely unambiguous. However, given Tim's strong opinions on >>the subject, it appears likely that such a proposal would not achieve >>consensus. > > This is curious since my reading of the threads looks like > there is rough concensus on Simple String Comparison > for the atom:id. First, I'll assert that the rules defined by [6] are Simple String Comparison, and I would certainly agree to them. I'm not sure that there is consensus, however. For example, my read is that Tim wants to enable Simple String Comparision but not preclude other comparisons[1], and that Mark wants to require all normalizations other than protocol normalization[2]. Few others have weighed in recently. My preference is that if we are going to allow multiple comparison algorithms, I want rules in place to ensure that all such comparisons get the same result. Canonicalization achieves that. - Sam Ruby [6] http://www.w3.org/TR/2004/REC-xml-names11-20040204/#IRIComparison [1] http://www.imc.org/atom-syntax/mail-archive/msg08143.html [2] http://www.imc.org/atom-syntax/mail-archive/msg08138.html From owner-atom-syntax@mail.imc.org Mon Aug 2 09:21:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05593 for ; Mon, 2 Aug 2004 09:21:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DBXDb055174; Mon, 2 Aug 2004 06:11:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72DBXfD055173; Mon, 2 Aug 2004 06:11:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DBWUx055158 for ; Mon, 2 Aug 2004 06:11:32 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so210333rnk for ; Mon, 02 Aug 2004 06:11:33 -0700 (PDT) Received: by 10.38.6.72 with SMTP id 72mr3758rnf; Mon, 02 Aug 2004 06:11:33 -0700 (PDT) Message-ID: <14be96d304080206113e2b320c@mail.gmail.com> Date: Mon, 2 Aug 2004 09:11:33 -0400 From: Mark Pilgrim To: Joe Gregorio Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Cc: Sam Ruby , Paul Hoffman / IMC , Tim Bray , Atom Syntax In-Reply-To: <3f1451f50408020500263fcf55@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410D698E.6080702@intertwingly.net> <3f1451f50408020500263fcf55@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2 Aug 2004 08:00:21 -0400, Joe Gregorio wrote: > > On Sun, 01 Aug 2004 18:07:10 -0400, Sam Ruby wrote: > > On the topic of ids, it seems that comparision is the key operation. My > > first preference would have been to define the rules precisely. One > > such set of rules would be those defined by Namespaces in XML 1.1[6] > > which are entirely unambiguous. However, given Tim's strong opinions on > > the subject, it appears likely that such a proposal would not achieve > > consensus. > > This is curious since my reading of the threads looks like > there is rough concensus on Simple String Comparison > for the atom:id. Well, it appears we've come full circle. Norman Walsh suggested that clients do simple string comparison [1], and Tim explicitly rejected it [2]. What Sam is suggesting is that clients do simple string comparison after the publisher canonicalizes the URI, i.e. publishing uncanonicalized URIs is an error. But only for atom:id, because it's special. (It is; its main purpose in life is for clients to compare it to other atom:id values. Thus, comparing should be made as simple as possible, without introducing ambiguity.) For that reason, I vehemently reject Tim's reasoning that "shit happens" and "clients will all act differently anyway," therefore we should throw up our hands, accept such differences, and bake ambiguity into the spec. You know what I call differences like that? "Bugs." We're not judging an elementary school science fair here, where everyone is a winner simply for participating. If two programs compare atom:ids for equivalence and come up with different answers, at least one of them is wrong and should be fixed ASAP. It's the spec's job to say which one. Why bother having an atom:id if you can't tell if they're equivalent? That's madness. +1 to Sam's proposal. Go write up PacePublisherNormalizesUri. I'll write up the test cases for the feed validator to check for non-canonical URIs in atom:id. All the clients in the world can continue doing what they're doing already. [1] http://intertwingly.net/wiki/pie/PaceFeedEquivalence [2] http://www.imc.org/atom-syntax/mail-archive/msg08059.html -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Mon Aug 2 09:30:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06114 for ; Mon, 2 Aug 2004 09:30:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DMmdm055806; Mon, 2 Aug 2004 06:22:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72DMmqC055805; Mon, 2 Aug 2004 06:22:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DMl1H055799 for ; Mon, 2 Aug 2004 06:22:48 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so142692rnl for ; Mon, 02 Aug 2004 06:22:49 -0700 (PDT) Received: by 10.38.24.21 with SMTP id 21mr215157rnx; Mon, 02 Aug 2004 06:22:49 -0700 (PDT) Message-ID: <3f1451f504080206227817b062@mail.gmail.com> Date: Mon, 2 Aug 2004 09:22:49 -0400 From: Joe Gregorio To: Sam Ruby Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Cc: Paul Hoffman / IMC , Tim Bray , Atom Syntax In-Reply-To: <410E36F7.7010802@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410D698E.6080702@intertwingly.net> <3f1451f50408020500263fcf55@mail.gmail.com> <410E36F7.7010802@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 02 Aug 2004 08:43:35 -0400, Sam Ruby wrote: > First, I'll assert that the rules defined by [6] are Simple String > Comparison, and I would certainly agree to them. Agreed. > My preference is that if we are going to allow multiple comparison > algorithms, I want rules in place to ensure that all such comparisons > get the same result. Canonicalization achieves that. Agreed. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Aug 2 10:03:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07900 for ; Mon, 2 Aug 2004 10:03:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DtAww058335; Mon, 2 Aug 2004 06:55:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72DtAlE058334; Mon, 2 Aug 2004 06:55:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Dt9ll058327 for ; Mon, 2 Aug 2004 06:55:09 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i72DuSGX026045 for ; Mon, 2 Aug 2004 09:56:28 -0400 Message-ID: <410E47BF.3090106@intertwingly.net> Date: Mon, 02 Aug 2004 09:55:11 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> In-Reply-To: <410D307B.9060101@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Unless there is violent objection, I'll write up a Pace. http://www.intertwingly.net/wiki/pie/PaceCanonicalIds All I did was to capture the rules defined by rfc 2396bis with two additions, and provide illustrative examples (which will serve as the basis for feedvalidator test cases). - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 2 10:15:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09348 for ; Mon, 2 Aug 2004 10:15:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72E48Jv059312; Mon, 2 Aug 2004 07:04:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72E48rl059308; Mon, 2 Aug 2004 07:04:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72E4832059274 for ; Mon, 2 Aug 2004 07:04:08 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id B0E0A7C0F3; Mon, 2 Aug 2004 16:58:46 +0200 (CEST) Date: Mon, 02 Aug 2004 16:08:52 +0200 To: "Laurent Le Meur" Subject: Re: RE : Identity conundrum ... and links Cc: Atom-Syntax References: <005a01c47876$e3a40db0$67b4329e@afp.local> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <005a01c47876$e3a40db0$67b4329e@afp.local> User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 2 Aug 2004 11:55:48 +0200, Laurent Le Meur wrote: > Let's imagine a comment about an opinion. If the author of the opinion > changes his mind after the comment is published, and updates his entry > without any change of identification, the comment will become totally > out of sync with the linked entry. Yep. This is right on the nail and the exact thing I've tried to express all along. Consensus seem to be (but I'm not sure) that such a model is too much to require from a blog tool, which I am not the right person to either validate or invalidate. > If the update of an entry is really significant (if its meaning/semantics > has changed) then can it still really be the same entry? I suggest that > it should rather be a new entry *derived from* (or superceding as in [1] > if I understand correctly) the previous one. Indeed. > Is it something worth mentioning in the 4.2.6 ("atom:id" Element) > paragraph? I'm not sure. That probably depends on what conensus is that atom:id should identify. If it's only going to identify what I call «a story» and not «story instances» or «versions», such language would not fit in the core specification. I think the core specification should say something about this, but I'm not sure what. What I am sure of, is that the versioning and more professional publishing model should be reflected with an extension. How this extension may look like is still very blue-ish, but I think Ken's very old proposal of just having a element in the , that exists in a known namespace, would be a good solution. Se this message for more details: > On the other side a/ for metadata modification or content corrections, > which do not imply a change of meaning of the content and b/ for dynamic > resources [2] like the front page of a web site or the TOC of a document, > links to the entry don't risk being semantically broken. Correct. I'm in no doubt that the better of the two models, in my opinion, is the versioning one. The problem is that I don't think we can enforce this model on anyone. Those who want it should be able to pick it, but those who don't should be able to pick that as well. > It may then be useful to put a revision mechanism in place and be able > to link to a certain revision of the entry but it is not required (the > NewsML and LSID URI schemes support revisions but many URI schemes > don't). Yes. That's why an extension mechanism that alters the semantics of atom:id also can alter the requirements for atom:id. Such an extension (or rather; profile) could state that «The content of atom:id MUST be created in a URI scheme that supports versioning», or even «The content of atom:id MUST be a NewsML URN». > Note: the debate on "update date-time" is related to this notion of > identity of an item and significant changes; given the moratorium on > dates, I won't comment on this part now. You're right, but I'll pipe down on the subject as well. :-) -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Aug 2 10:40:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11251 for ; Mon, 2 Aug 2004 10:40:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72EW2So061081; Mon, 2 Aug 2004 07:32:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72EW2QV061080; Mon, 2 Aug 2004 07:32:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72EW1ah061067; Mon, 2 Aug 2004 07:32:01 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i72EW3il022430; Mon, 2 Aug 2004 08:32:03 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1T00MLXPPE01@edgemail1.Central.Sun.COM>; Mon, 02 Aug 2004 08:32:03 -0600 (MDT) Received: from [130.129.135.42] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1T00FVKPPELB@mail.sun.net>; Mon, 02 Aug 2004 08:32:02 -0600 (MDT) Date: Mon, 02 Aug 2004 07:32:24 -0700 From: Tim Bray Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) In-reply-to: <410E36F7.7010802@intertwingly.net> To: Sam Ruby Cc: Joe Gregorio , Atom Syntax , Paul Hoffman / IMC Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410D698E.6080702@intertwingly.net> <3f1451f50408020500263fcf55@mail.gmail.com> <410E36F7.7010802@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 2, 2004, at 5:43 AM, Sam Ruby wrote: > I'm not sure that there is consensus, however. For example, my read > is that Tim wants to enable Simple String Comparision but not preclude > other comparisons[1], and that Mark wants to require all > normalizations other than protocol normalization[2]. Few others have > weighed in recently. I want to go further and explicitly encourage simple string comparisons, but as your tests proved, doing simple-looking things like URI.equals() in Java and C# does more than that, and since this can never produce a false positive in real life, i.e., since it can never cause a problem, why write text to "preclude" it? In Java/C#, the fact that you can do anything.equals(anythingElse) is actually kind of useful in some spots and it seems unnecessary and irritating if I have to write boolean test; if (anything instanceof atomID) test = anything.toString().equals(anythingElse.toString()); else test = anything.equals(anythingElse); if (test) .... > My preference is that if we are going to allow multiple comparison > algorithms, I want rules in place to ensure that all such comparisons > get the same result. Canonicalization achieves that. and, as you pointed out it's usually unnecessary and typically cheap. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 2 10:43:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11464 for ; Mon, 2 Aug 2004 10:43:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72EYUb7061193; Mon, 2 Aug 2004 07:34:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72EYUK7061192; Mon, 2 Aug 2004 07:34:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72EYUJQ061186 for ; Mon, 2 Aug 2004 07:34:30 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i72EYWil023687 for ; Mon, 2 Aug 2004 08:34:32 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1T00EELPTJYX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 02 Aug 2004 08:34:32 -0600 (MDT) Received: from [130.129.135.42] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1T00FW5PTJLB@mail.sun.net> for atom-syntax@imc.org; Mon, 02 Aug 2004 08:34:31 -0600 (MDT) Date: Mon, 02 Aug 2004 07:34:54 -0700 From: Tim Bray Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) In-reply-to: <410E47BF.3090106@intertwingly.net> To: Sam Ruby Cc: Atom Syntax Message-id: <1E846DCA-E491-11D8-B820-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410E47BF.3090106@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 2, 2004, at 6:55 AM, Sam Ruby wrote: > > Sam Ruby wrote: >> Unless there is violent objection, I'll write up a Pace. > > http://www.intertwingly.net/wiki/pie/PaceCanonicalIds > > All I did was to capture the rules defined by rfc 2396bis with two > additions, and provide illustrative examples (which will serve as the > basis for feedvalidator test cases). +1 If we're going to require canonicalization of atom:id, we could go further and require all URIs in and so on to be canonicalized, or at least suggest it with a SHOULD. Makes all sorts of irritating little problems go away. But then as a spider wrangler, I'm prejudiced :) -Tim From owner-atom-syntax@mail.imc.org Mon Aug 2 10:57:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11853 for ; Mon, 2 Aug 2004 10:57:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72EluLI061810; Mon, 2 Aug 2004 07:47:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72EluBr061809; Mon, 2 Aug 2004 07:47:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72ElsUm061803 for ; Mon, 2 Aug 2004 07:47:55 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 51D807C0F3; Mon, 2 Aug 2004 17:42:38 +0200 (CEST) To: "Sam Ruby" Cc: Atom-Syntax Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410E47BF.3090106@intertwingly.net> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 02 Aug 2004 16:51:46 +0200 In-Reply-To: <410E47BF.3090106@intertwingly.net> User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 02 Aug 2004 09:55:11 -0400, Sam Ruby wrote: > http://www.intertwingly.net/wiki/pie/PaceCanonicalIds I guess this pace should be easilly mergable with any other atom:id pace, so: +1. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Aug 2 12:15:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16115 for ; Mon, 2 Aug 2004 12:15:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72G2og0066274; Mon, 2 Aug 2004 09:02:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72G2oho066273; Mon, 2 Aug 2004 09:02:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] ([130.129.129.118]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72G2mnf066267 for ; Mon, 2 Aug 2004 09:02:49 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <410D698E.6080702@intertwingly.net> References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410D698E.6080702@intertwingly.net> Date: Mon, 2 Aug 2004 09:02:54 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>I non-violently object because I don't understand one of the >>pillars of your proposal. > >In the immortal words of an author of two very large-scale web >spiders that have processed in aggregate in excess of a billion >URLs[2], contributor to rfc 2396bis[3], and co-chair of this working >group[4], "shit happens"[5]. Fully agree. >Also, note that the napkins, busses, and keynotes comment was >derived from another comment by Tim Bray[1]. Tim never said that Atom IDs would show up in any of those place. This is *exactly* the problem if using URIs as Atom IDs: people think that the two have similar properties in the real world. >On the topic of ids, it seems that comparision is the key operation. >My first preference would have been to define the rules precisely. >One such set of rules would be those defined by Namespaces in XML >1.1[6] which are entirely unambiguous. However, given Tim's strong >opinions on the subject, it appears likely that such a proposal >would not achieve consensus. Tim is one member of the WG, and is no more important than anyone else. I will soon propose that atom:id is a plain-old-text string, and that atom:link is the thing that is dereferenceable. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Aug 2 12:55:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18554 for ; Mon, 2 Aug 2004 12:55:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72GmSOC069451; Mon, 2 Aug 2004 09:48:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72GmSJU069450; Mon, 2 Aug 2004 09:48:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72GmRTV069436; Mon, 2 Aug 2004 09:48:27 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 8DABF7C0F3; Mon, 2 Aug 2004 19:43:10 +0200 (CEST) To: "Paul Hoffman / IMC" Cc: Atom-Syntax Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410D698E.6080702@intertwingly.net> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 02 Aug 2004 18:52:50 +0200 In-Reply-To: User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 2 Aug 2004 09:02:54 -0700, Paul Hoffman / IMC wrote: > I will soon propose that atom:id is a plain-old-text string, and that > atom:link is the thing that is dereferenceable. I would not be -1 on that. (Initially, at least.) -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Aug 2 13:37:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20972 for ; Mon, 2 Aug 2004 13:37:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72HTlKN073461; Mon, 2 Aug 2004 10:29:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72HTlGR073460; Mon, 2 Aug 2004 10:29:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i72HTl76073442 for ; Mon, 2 Aug 2004 10:29:47 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040802172943.96376.qmail@web41205.mail.yahoo.com> Received: from [207.46.228.98] by web41205.mail.yahoo.com via HTTP; Mon, 02 Aug 2004 10:29:43 PDT Date: Mon, 2 Aug 2004 10:29:43 -0700 (PDT) From: Dare Obasanjo Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) To: Sam Ruby , Paul Hoffman / IMC Cc: Tim Bray , Atom Syntax In-Reply-To: <410D698E.6080702@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Sam Ruby wrote: > > On the topic of ids, it seems that comparision is > the key operation. My > first preference would have been to define the rules > precisely. One > such set of rules would be those defined by > Namespaces in XML 1.1[6] > which are entirely unambiguous. However, given > Tim's strong opinions on > the subject, it appears likely that such a proposal > would not achieve > consensus. So if one person objects we can't reach consensus? > So, given this reality - and in the interest of > interoperability - if we > can't constrain how ids are compared, I would like > to constrain how ids > are expressed. Simply put, if people are permitted > to use the .Net > Uri.Equals or the Java URI.equals methods to > determine atom:id > equivalence, I want to make sure that they don't > ever treat two distinct > URIs as equivalent. This looks like you are trying to 'hack around' Tim's objections by achieve the same thing with different wording. If URIs are always in canonical form then there is no need to specify the comparison algorithm. It seems like a case of six of one and half a dozen of the other. +1 either way. > Looking at the rfc 2396bis rules, they seem very > reasonable and natural. > In fact, none of the URI's listed after my > signature would violate any > of them. Good. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Mon Aug 2 14:13:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23878 for ; Mon, 2 Aug 2004 14:13:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72I3ibx075995; Mon, 2 Aug 2004 11:03:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72I3i0Q075994; Mon, 2 Aug 2004 11:03:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i72I3hLM075982 for ; Mon, 2 Aug 2004 11:03:44 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 8010 invoked from network); 2 Aug 2004 18:06:07 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 2 Aug 2004 18:06:07 -0000 Subject: Re: RE : Identity conundrum From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Atom syntax In-Reply-To: References: <005a01c47876$e3a40db0$67b4329e@afp.local> Content-Type: text/plain Message-Id: <1091469841.2024.32.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 02 Aug 2004 19:04:01 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Could someone explain the motivation to generate a unique ID value, URI or otherwise, for the manual blog author? Seems fine to argue over the minute detail of comparing two, I'm curious what happens when 3000 http://example.com 'id' values show up in blogspace? Curious DaveP. From owner-atom-syntax@mail.imc.org Mon Aug 2 14:31:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25342 for ; Mon, 2 Aug 2004 14:31:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72IONg4077763; Mon, 2 Aug 2004 11:24:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72IONMx077762; Mon, 2 Aug 2004 11:24:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i72IONpC077754 for ; Mon, 2 Aug 2004 11:24:23 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040802182417.49893.qmail@web41207.mail.yahoo.com> Received: from [207.46.238.138] by web41207.mail.yahoo.com via HTTP; Mon, 02 Aug 2004 11:24:17 PDT Date: Mon, 2 Aug 2004 11:24:17 -0700 (PDT) From: Dare Obasanjo Subject: Re: RE : Identity conundrum To: davep@dpawson.co.uk, Atom syntax In-Reply-To: <1091469841.2024.32.camel@homer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Dave Pawson wrote: > > Could someone explain the motivation to generate a > unique ID > value, URI or otherwise, for the manual blog author? > > Seems fine to argue over the minute detail of > comparing two, > I'm curious what happens when 3000 > http://example.com 'id' values > show up in blogspace? http://www.imc.org/atom-syntax/mail-archive/msg07874.html ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Mon Aug 2 14:34:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25540 for ; Mon, 2 Aug 2004 14:34:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72IPoiB078025; Mon, 2 Aug 2004 11:25:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72IPoq7078024; Mon, 2 Aug 2004 11:25:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72IPnqY078018 for ; Mon, 2 Aug 2004 11:25:49 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i72IR3DY005719; Mon, 2 Aug 2004 14:27:04 -0400 Message-ID: <410E872B.3010601@intertwingly.net> Date: Mon, 02 Aug 2004 14:25:47 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: davep@dpawson.co.uk CC: Atom syntax Subject: Re: RE : Identity conundrum References: <005a01c47876$e3a40db0$67b4329e@afp.local> <1091469841.2024.32.camel@homer> In-Reply-To: <1091469841.2024.32.camel@homer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave Pawson wrote: > Could someone explain the motivation to generate a unique ID > value, URI or otherwise, for the manual blog author? > > Seems fine to argue over the minute detail of comparing two, > I'm curious what happens when 3000 http://example.com 'id' values > show up in blogspace? > > Curious DaveP. Simple answer: last one wins. A frequent complaint that aggregator authors receive is that users get to see entries multiple times. One reason for this is the lack of feeds consistently providing ids. Another is that sites that republish other feeds typically assign a new id. If we can make meaningful progress towards addressing these two problems, then aggregators can identify whether or not the user has seen this entry before. Once we get that far, there are more questions. What if the content is different than was seen previously? One school of thought is to disallow this, and require that all changes require new a id to be assigned. Another is to allow the producer to provide some sort of indication as to whether this was a minor change unworthy of attention or significant - something Tim Bray attempts to accomplish today by changing pubDate, with some success in NetNewsWire and without success in RssBandit. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 2 14:36:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25643 for ; Mon, 2 Aug 2004 14:36:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72IR7iR078072; Mon, 2 Aug 2004 11:27:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72IR73i078071; Mon, 2 Aug 2004 11:27:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72IR6sN078057 for ; Mon, 2 Aug 2004 11:27:07 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i72IR453005465 for ; Mon, 2 Aug 2004 13:27:05 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i72IR4lj005461; Mon, 2 Aug 2004 13:27:04 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom syntax Subject: Re: RE : Identity conundrum References: <005a01c47876$e3a40db0$67b4329e@afp.local> <1091469841.2024.32.camel@homer> From: Ken MacLeod Date: 02 Aug 2004 13:27:04 -0500 In-Reply-To: <1091469841.2024.32.camel@homer> Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Pawson writes: > Seems fine to argue over the minute detail of comparing two, I'm > curious what happens when 3000 http://example.com 'id' values show > up in blogspace? Newsreaders that support IDs (guid in RSS 2.0, rdf:about in RSS 1.0) will only display one copy of an entry with the same ID. Other entries will be discarded. > Could someone explain the motivation to generate a unique ID value, > URI or otherwise, for the manual blog author? The motivation for *having* an ID is to know when to entries *are* the same entry, so they are not redisplayed as new. Some newsreaders will go a little further and indicate if an "already seen" entry has changed, but it won't be reported as a new entry (ie. won't pop to the "top" of the list, it'll only be highlighted or flagged in some way). The way this was done prior to guid/rdf:about depended on the title or permalink not changing (where many permalinks are based on the title anyway), but that has a lot of other problems. -- Ken From owner-atom-syntax@mail.imc.org Mon Aug 2 15:15:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28336 for ; Mon, 2 Aug 2004 15:15:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72J3tmG080796; Mon, 2 Aug 2004 12:03:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72J3tU2080795; Mon, 2 Aug 2004 12:03:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i72J3sgv080788 for ; Mon, 2 Aug 2004 12:03:54 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 1008 invoked from network); 2 Aug 2004 19:06:22 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 2 Aug 2004 19:06:22 -0000 Subject: Re: RE : Identity conundrum From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Ken MacLeod Cc: Atom syntax In-Reply-To: References: <005a01c47876$e3a40db0$67b4329e@afp.local> <1091469841.2024.32.camel@homer> Content-Type: text/plain Message-Id: <1091473456.2024.47.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 02 Aug 2004 20:04:16 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-08-02 at 19:27, Ken MacLeod wrote: > > Could someone explain the motivation to generate a unique ID value, > > URI or otherwise, for the manual blog author? > > The motivation for *having* an ID is to know when to entries *are* the > same entry, so they are not redisplayed as new. I see this as a 'reader' view? Dare notes, pragmatically, that if an author cares, The point is that experience has taught us that if people can use HTTP URLs as identifiers, they will use permalinks not some abstract "globally unique identifier". Sam notes A frequent complaint that aggregator authors receive is that users get to see entries multiple times. One reason for this is the lack of feeds consistently providing ids. Is the implication that I'll only seek to use a unique ID value if I care about how my musings are collated/distributed? Dare I say vanity? Is that sufficient motivation? Instance: A new author, hasn't bought a domain name, isn't using blogging atom software, where does he dream up his uri? Will Atom provide a stream of these? What will the blogging software do? Use the product uri+... something? Dare's solution is pragmatic for some cases, where they can be de-referenced. For other cases? -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Mon Aug 2 16:14:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01525 for ; Mon, 2 Aug 2004 16:14:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72K2UgP086503; Mon, 2 Aug 2004 13:02:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72K2UAo086502; Mon, 2 Aug 2004 13:02:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i72K2Ra7086480 for ; Mon, 2 Aug 2004 13:02:30 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 16114 invoked by uid 65534); 2 Aug 2004 20:02:21 -0000 Received: from dsl-082-083-167-012.arcor-ip.net (EHLO localhost) (82.83.167.12) by mail.gmx.net (mp020) with SMTP; 02 Aug 2004 22:02:21 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Sam Ruby Cc: atom-syntax@imc.org Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Date: Mon, 02 Aug 2004 22:02:12 +0200 Message-ID: <411c9a56.785057402@smtp.bjoern.hoehrmann.de> References: <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> In-Reply-To: <410D307B.9060101@intertwingly.net> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Sam Ruby wrote: >So, if we can't control how ids are consumed or transmitted, we control >what we can: ids are recorded. We have the Atom specification require >that all ids MUST be in a canonical form. We start with the rules in >rfc 2396bis[2]. We add a few: URIs can't be relative. URIs must be >utf-8, in fact must be NFC (or whatever form we select). For schemes >which define an option port, we require that all ports be explicit (or >alternately, we require any ports that match the default for the scheme >chosen be omitted). I think I am opposed to any conformance criteria for which one cannot write software that determines whether the criteria are met. Here in particular it is not possible to determine whether the default port is omitted or not as that would require to know the default port which would require to know about all present and future schemes. The other criteria you cite are also problematic. It would be okay to stuff such criteria into a separate layer, e.g. one that differentiates whether Atom documents using extensions use these extensions properly. From owner-atom-syntax@mail.imc.org Mon Aug 2 16:46:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04490 for ; Mon, 2 Aug 2004 16:46:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KaNLC088806; Mon, 2 Aug 2004 13:36:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72KaN0S088805; Mon, 2 Aug 2004 13:36:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KaMOY088798 for ; Mon, 2 Aug 2004 13:36:22 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i72Kbg8l011912; Mon, 2 Aug 2004 16:37:42 -0400 Message-ID: <410EA5C8.4040907@intertwingly.net> Date: Mon, 02 Aug 2004 16:36:24 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Hoehrmann CC: atom-syntax@imc.org Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <411c9a56.785057402@smtp.bjoern.hoehrmann.de> In-Reply-To: <411c9a56.785057402@smtp.bjoern.hoehrmann.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bjoern Hoehrmann wrote: > * Sam Ruby wrote: > >>So, if we can't control how ids are consumed or transmitted, we control >>what we can: ids are recorded. We have the Atom specification require >>that all ids MUST be in a canonical form. We start with the rules in >>rfc 2396bis[2]. We add a few: URIs can't be relative. URIs must be >>utf-8, in fact must be NFC (or whatever form we select). For schemes >>which define an option port, we require that all ports be explicit (or >>alternately, we require any ports that match the default for the scheme >>chosen be omitted). > > I think I am opposed to any conformance criteria for which one cannot > write software that determines whether the criteria are met. Here in > particular it is not possible to determine whether the default port is > omitted or not as that would require to know the default port which > would require to know about all present and future schemes. The other > criteria you cite are also problematic. It would be okay to stuff such > criteria into a separate layer, e.g. one that differentiates whether > Atom documents using extensions use these extensions properly. Presumably, if you chose to support a given scheme, you understand that scheme. As an example, Tim Bray is likely to use http, and probably has already figured out that port 80 is the default for that scheme. For the feedvalidator, I'll probably start with the following set: ftp: 21 telnet: 23 gopher: 70 http: 80 news: 119 nntp: 119 prospero: 191 https: 443 snews: 563 snntp: 563 - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 2 17:33:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06733 for ; Mon, 2 Aug 2004 17:33:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LQdPn092433; Mon, 2 Aug 2004 14:26:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72LQd1x092432; Mon, 2 Aug 2004 14:26:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LQcol092426 for ; Mon, 2 Aug 2004 14:26:38 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i72LRwHa014195; Mon, 2 Aug 2004 17:27:58 -0400 Message-ID: <410EB191.8030302@intertwingly.net> Date: Mon, 02 Aug 2004 17:26:41 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: davep@dpawson.co.uk CC: Atom syntax Subject: Re: RE : Identity conundrum References: <005a01c47876$e3a40db0$67b4329e@afp.local> <1091469841.2024.32.camel@homer> <1091473456.2024.47.camel@homer> In-Reply-To: <1091473456.2024.47.camel@homer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave Pawson wrote: > > Is the implication that I'll only seek to use a unique ID > value if I care about how my musings are collated/distributed? > Dare I say vanity? Fetch http://www.intertwingly.net/blog/index.atom, and you will see approximately 20 entries. Fetch it each hour, on the hour, you will see a total of 480 entries. Many of them you will have seen before. Now, fetch http://www.planetapache.org/rss10.xml. You will see some of the same entries. Now start fetching that feed hourly. Pretty soon you will be wanting an algorithm which allows you to determine if you have seen an entry before. A first order approximation would be to use the link element. This works very well if you are very careful, and works reasonably well if you aren't. Unfortunately, if you are a consumer, reasonably well times dozens of feeds over a period of months means that you will see failures. And if you are an aggregator vendor with hundreds, if not thousands, of users, that means that you will hear complaints daily. That's why there is so much interest in picking an id scheme that encourages best practices. - Sam Ruby P.S. Your XSLT faq was *very* helpful when I was learning XSLT nearly four years ago. I still reference it periodically. Thanks! From owner-atom-syntax@mail.imc.org Mon Aug 2 17:45:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07489 for ; Mon, 2 Aug 2004 17:45:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LcZRt094359; Mon, 2 Aug 2004 14:38:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72LcZ8q094358; Mon, 2 Aug 2004 14:38:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LcZCv094350 for ; Mon, 2 Aug 2004 14:38:35 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i72LcbT6003983; Mon, 2 Aug 2004 17:38:37 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BLE24176 (AUTH bob@wyman.us); Mon, 2 Aug 2004 17:38:35 -0400 (EDT) Message-Id: <200408022138.BLE24176@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" , "'Tim Bray'" Cc: "'Atom Syntax'" Subject: RE: URI equivalence (was Re: PaceFeedEquivalence) Date: Mon, 2 Aug 2004 17:38:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <410D307B.9060101@intertwingly.net> Thread-Index: AcR39FLp9nH9fW9hQ4qumCgJsvny6gA4i88w Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > we require that all ports be explicit (or > alternately, we require any ports that match > the default for the scheme chosen be omitted). These words seem to assume "old style" port assignment practices. (I.e. the use of fixed ports). New protocols are "supposed" to use DNS SRV records to disclose port assignments and some actually do (i.e. BEEP, APEX, and a few others). To *require* that ports be explicit seems to risk making unreasonable constraints on some schemes and would root Atom in practices that many would argue should be discouraged. bob wyman From owner-atom-syntax@mail.imc.org Mon Aug 2 17:53:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08108 for ; Mon, 2 Aug 2004 17:53:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LlCKw095811; Mon, 2 Aug 2004 14:47:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72LlCap095810; Mon, 2 Aug 2004 14:47:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72LlBfM095802 for ; Mon, 2 Aug 2004 14:47:11 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i72LmWPq015194; Mon, 2 Aug 2004 17:48:32 -0400 Message-ID: <410EB663.4040300@intertwingly.net> Date: Mon, 02 Aug 2004 17:47:15 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Atom Syntax'" Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <200408022138.BLE24176@ms8.netsolmail.com> In-Reply-To: <200408022138.BLE24176@ms8.netsolmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Sam Ruby wrote: > >>we require that all ports be explicit (or >>alternately, we require any ports that match >>the default for the scheme chosen be omitted). > > These words seem to assume "old style" port assignment practices. > (I.e. the use of fixed ports). New protocols are "supposed" to use DNS SRV > records to disclose port assignments and some actually do (i.e. BEEP, APEX, > and a few others). To *require* that ports be explicit seems to risk making > unreasonable constraints on some schemes and would root Atom in practices > that many would argue should be discouraged. I presume that you are catching up on email... upon further reflection, I decided to flip that. See: http://www.intertwingly.net/wiki/pie/PaceCanonicalIds - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 2 20:54:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19078 for ; Mon, 2 Aug 2004 20:54:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i730hbY9008084; Mon, 2 Aug 2004 17:43:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i730hbVK008083; Mon, 2 Aug 2004 17:43:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i730haxa008077 for ; Mon, 2 Aug 2004 17:43:36 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail17.mac.com (webmail17-en1 [10.13.10.159]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i730hgtR000659 for ; Mon, 2 Aug 2004 17:43:42 -0700 (PDT) Received: from webmail17 (localhost [127.0.0.1]) by webmail17.mac.com (8.12.6/8.12.2) with ESMTP id i730hgiQ019932 for ; Mon, 2 Aug 2004 17:43:42 -0700 (PDT) Message-ID: <14290954.1091493822057.JavaMail.dtcd@mac.com> Date: Tue, 03 Aug 2004 01:43:42 +0100 From: Graham Parks To: atom-syntax@imc.org Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Mime-Version: 1.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: Content-Transfer-Encoding: 7bit On 2 Aug 2004, at 8:43 am, Sam Ruby wrote: > My preference is that if we are going to allow multiple comparison algorithms, I want rules in place > to ensure that all such comparisons get the same result. Why don't we do just that? i) It is an error to provide ids that are meant to be the same that fail simple string comparison. ii) It is an error to provide ids that are meant to be different but match after normalization. I also don't ever see atom:id's being passed around by humans ever (what with not being dereferencable and all). Graham From owner-atom-syntax@mail.imc.org Mon Aug 2 21:20:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20426 for ; Mon, 2 Aug 2004 21:20:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i731D7gf009952; Mon, 2 Aug 2004 18:13:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i731D7UH009951; Mon, 2 Aug 2004 18:13:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i731D6dw009945 for ; Mon, 2 Aug 2004 18:13:06 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i731ETq1024453; Mon, 2 Aug 2004 21:14:29 -0400 Message-ID: <410EE6A7.30502@intertwingly.net> Date: Mon, 02 Aug 2004 21:13:11 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: atom-syntax@imc.org Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14290954.1091493822057.JavaMail.dtcd@mac.com> In-Reply-To: <14290954.1091493822057.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Graham Parks wrote: > On 2 Aug 2004, at 8:43 am, Sam Ruby wrote: > >>My preference is that if we are going to allow multiple comparison algorithms, I want rules in place >>to ensure that all such comparisons get the same result. > > Why don't we do just that? > > i) It is an error to provide ids that are meant to be the same that fail simple string comparison. > ii) It is an error to provide ids that are meant to be different but match after normalization. Who would one detect "meant to be different but match after normalization"? Forgive me, but this sounds to me pretty much ? Removing paragraph about atom:id not working and trusting people to get it right ? [1] - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg08110.html From owner-atom-syntax@mail.imc.org Mon Aug 2 23:17:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25336 for ; Mon, 2 Aug 2004 23:17:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7336204018494; Mon, 2 Aug 2004 20:06:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73362hv018493; Mon, 2 Aug 2004 20:06:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i733601p018481 for ; Mon, 2 Aug 2004 20:06:01 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7336253010023 for ; Mon, 2 Aug 2004 22:06:02 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i73361aq010019; Mon, 2 Aug 2004 22:06:01 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: atom-syntax@imc.org Subject: Atom assertion-annotated specifications From: Ken MacLeod Date: 02 Aug 2004 22:06:01 -0500 Message-ID: Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [Also posted at http://bitsko.slc.ut.us/blog/atom-anno-specs.html] In addition to the Feed Validator[1], there are a (slowly) growing number of Atom conformance tests[2] (for feeds, aggregators, and more) and interest in getting more test suites started. I've been reading up on Quality Assurance at W3C [3] (IETF and OASIS don't have QA guidelines, that I'm aware of) and one of the "next big steps" in connecting-the-dots between specifications, test suites, and implementation reports is a list of all the assertions in the specification, so that tests can be linked to the assertion in the specification that they test, and implementations can report which features (assertions) they implement and which tests they pass. I now have an early release of the assertions in the Atom Format and Protocol (-01 version of both) as highlighted and annotated versions of the specifications. Each assertion is highlighted in yellow and given a sequential assertion number within each section. (Note: these assertion numbers are not yet stable in this release.) The source for the annotation script and feature lists is in the same directory. http://bitsko.slc.ut.us/2004/08/atom-qa/format-01-anno.html http://bitsko.slc.ut.us/2004/08/atom-qa/protocol-01-anno.html The next little steps with the assertion list is to get it formatted into its own pair of documents to provide a check-list for test suites, and include such information as the [version stable] assertion-ID, whether the specified behavior is required or optional, and the roles that the behavior applies to (feed producer, aggregator, editing client, etc.) We'll see where the next big steps take us after that... -- Ken [1] http://feedvalidator.org/ [2] http://intertwingly.net/wiki/pie/ConformanceTests [3] http://www.w3.org/QA/ From owner-atom-syntax@mail.imc.org Tue Aug 3 05:26:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26669 for ; Tue, 3 Aug 2004 05:26:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7399m8L014111; Tue, 3 Aug 2004 02:09:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7399mMu014110; Tue, 3 Aug 2004 02:09:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01-ext.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7399miw014091 for ; Tue, 3 Aug 2004 02:09:48 -0700 (PDT) (envelope-from dorchard@bea.com) Received: from ussjfe01.amer.bea.com (ussjfe01b.bea.com [172.16.120.57]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id i7399jRV020698; Tue, 3 Aug 2004 02:09:46 -0700 Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Aug 2004 02:09:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PaceBasicAtomID - maybe we're done Date: Tue, 3 Aug 2004 02:09:44 -0700 Message-ID: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> Thread-Topic: PaceBasicAtomID - maybe we're done Thread-Index: AcR2qLLBv6TEwWWZQEerrkE5IGdGNwCBJGnA From: "David Orchard" To: "Mark Pilgrim" Cc: "Atom-Syntax" X-OriginalArrivalTime: 03 Aug 2004 09:09:45.0810 (UTC) FILETIME=[9ED56B20:01C47939] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7399miw014104 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit So let me understand this. You don't want to use HTTP URIs because Verisign totally and royally screwed up one domain. So throw out the identification scheme of the widest deployed distributed computer system ever because of 1 bad policy judgement. Seems like baby/bathwater or nose/spiting face kind of argument. Dave > -----Original Message----- > From: Mark Pilgrim [mailto:pilgrim@gmail.com] > Sent: Saturday, July 31, 2004 3:47 AM > To: David Orchard > Cc: Atom-Syntax > Subject: Re: PaceBasicAtomID - maybe we're done > > On Fri, 30 Jul 2004 16:39:30 -0700, David Orchard > wrote: > > > > I don't understand this argument. An HTTP URI is owned by the domain > authority. It's as persistent as that authority decides. > > You say that like it's a good thing. > > http://textism.com/article/494 > > -- > Cheers, > -Mark From owner-atom-syntax@mail.imc.org Tue Aug 3 06:26:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00369 for ; Tue, 3 Aug 2004 06:26:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73A91Bl036512; Tue, 3 Aug 2004 03:09:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73A912h036511; Tue, 3 Aug 2004 03:09:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id i73A9087036489 for ; Tue, 3 Aug 2004 03:09:01 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 92000 messnum 2123633 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 3 Aug 2004 10:05:24 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail03.svc.cra.dublin.eircom.net (qp 92000) with SMTP; 3 Aug 2004 10:05:24 -0000 Message-ID: <410F6360.9000800@dehora.net> Date: Tue, 03 Aug 2004 11:05:20 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Orchard wrote: > So let me understand this. You don't want to use HTTP URIs because > Verisign totally and royally screwed up one domain. So throw out the > identification scheme of the widest deployed distributed computer system > ever because of 1 bad policy judgement. Seems like baby/bathwater or > nose/spiting face kind of argument. I think the issue is to do with domain names per say; specifically how they are distributed and that thye seem to be more transient than we would like. It's not clear in who's favour or how relevant it is that it's a widely deployed scheme. (widest? really?) cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 3 08:11:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04995 for ; Tue, 3 Aug 2004 08:11:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73BwLLt055136; Tue, 3 Aug 2004 04:58:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73BwLRP055135; Tue, 3 Aug 2004 04:58:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73BwK2n055124 for ; Tue, 3 Aug 2004 04:58:21 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i73BxchW023722; Tue, 3 Aug 2004 07:59:38 -0400 Message-ID: <410F7DDB.6060200@intertwingly.net> Date: Tue, 03 Aug 2004 07:58:19 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Orchard CC: Atom-Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit David Orchard wrote: > So let me understand this. You don't want to use HTTP URIs because > Verisign totally and royally screwed up one domain. So throw out the > identification scheme of the widest deployed distributed computer system > ever because of 1 bad policy judgement. Seems like baby/bathwater or > nose/spiting face kind of argument. You are wildly overstating this. Yes, there are people who feel that HTTP is the one true protocol and that every URI should use the HTTP scheme, and URIs should be permanent and all content once issued should never unchange. And, yes, there are people who feel that anything but HTTP should be used instead for ids as there is an identifiable risk that the URI could change, and this risk is to be avoided at all costs. For now, let's ignore both extremes. = = = Instead lets look at the middle ground. There is a need for something called an id. In many cases (particularly ones in which you are the registered owner of the domain) where HTTP can serve this purpose well. In cases where you are not the registered owner (either because you represent a product of larger corporation which could be viewed as an asset to be sold), or because your portion of the URL space is made available by the graciousness of others, HTTP isn't quite so good a fit. There are other factors involved. Look at Georgic [1] "Too bad, I’m not changing the title". What would happen if Tim *did* change the title? Well the title is in the URI... from a locator perspective, this is not a big problem as you can set up redirection. From an identifier perspective, this represents a problem. And one other factor is that a culture has grown up around URIs whereby it is expected that the comparision between the two is to be "fuzzy". Case may change in some portions of the URI but not others. Various characters can be escaped or not, and some can be escaped in multiple ways. All these factors combined represent a very real problem. You can see the joy in Dare's response[2] to PaceAtomIDIsNewsML. Nothing to date has required rfd:about nor rss:guid to be the permalink, but it has been so widely assumed that making it so was a best practice, enough so that Dare sees enough the problems with the current assumptions and specification text that he states that it is actively "harmful to a positive user experience".[3] So... what's this middle ground that I'm alluding to? Let people use the URI scheme that they want; simply state the contract by which the URIs when used as ids must conform to. And since HTTP is widely known, document at least one other scheme so that people can be aware of the tradeoffs. And constrain the id to ensure interoperation when fuzzy comparisons are done. I predict that if this is done for ids, those that want to conflate identity with location will ensure that their permalinks are canonicalized too. And that would not be a bad thing. So... feel free to use your permalinks as identifiers. I suspect that you understand the identity contract better than most. - Sam Ruby [1] http://www.tbray.org/ongoing/When/200x/2004/07/31/Georgic [2] http://www.imc.org/atom-syntax/mail-archive/msg07856.html [3] http://www.imc.org/atom-syntax/mail-archive/msg07862.html From owner-atom-syntax@mail.imc.org Tue Aug 3 10:36:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12687 for ; Tue, 3 Aug 2004 10:36:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73EMcXS067762; Tue, 3 Aug 2004 07:22:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73EMcPq067761; Tue, 3 Aug 2004 07:22:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id i73EMbk5067752 for ; Tue, 3 Aug 2004 07:22:38 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 55344 messnum 2157056 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 3 Aug 2004 14:06:26 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail09.svc.cra.dublin.eircom.net (qp 55344) with SMTP; 3 Aug 2004 14:06:26 -0000 Message-ID: <410F9BDE.4030707@dehora.net> Date: Tue, 03 Aug 2004 15:06:22 +0100 From: =?windows-1252?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> In-Reply-To: <410F7DDB.6060200@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > So... what's this middle ground that I'm alluding to? Let people use > the URI scheme that they want; simply state the contract by which the > URIs when used as ids must conform to. And since HTTP is widely known, > document at least one other scheme so that people can be aware of the > tradeoffs. +1. Well said. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 3 11:14:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14639 for ; Tue, 3 Aug 2004 11:14:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73EuN2n069936; Tue, 3 Aug 2004 07:56:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73EuN9g069935; Tue, 3 Aug 2004 07:56:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73EuM3e069929 for ; Tue, 3 Aug 2004 07:56:22 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i73Es353001223 for ; Tue, 3 Aug 2004 08:54:03 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1V00018LI040@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 03 Aug 2004 08:56:25 -0600 (MDT) Received: from [192.168.1.15] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1V001QJLHXFF@mail.sun.net> for atom-syntax@imc.org; Tue, 03 Aug 2004 08:56:22 -0600 (MDT) Date: Tue, 03 Aug 2004 07:56:42 -0700 From: Tim Bray Subject: Re: PaceBasicAtomID - maybe we're done In-reply-to: <410F7DDB.6060200@intertwingly.net> To: Sam Ruby Cc: David Orchard , Atom-Syntax Message-id: <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=WINDOWS-1252; format=flowed References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i73EuN3e069930 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Aug 3, 2004, at 4:58 AM, Sam Ruby wrote: > There are other factors involved. Look at Georgic [1] "Too bad, I’m > not changing the title". What would happen if Tim *did* change the > title? Well the title is in the URI... from a locator perspective, > this is not a big problem as you can set up redirection. From an > identifier perspective, this represents a problem. No, at ongoing, the title of the article and its URI are 100% decoupled. I change titles all the time without breaking URIs. The fact that in that entry they're the same is a coincidence, look at some others. The auto-generation of URIs from titles is a filthy web-hostile practice that should be stopped. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 3 11:26:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15478 for ; Tue, 3 Aug 2004 11:26:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73FGRms071571; Tue, 3 Aug 2004 08:16:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73FGRLk071569; Tue, 3 Aug 2004 08:16:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73FGPxI071541 for ; Tue, 3 Aug 2004 08:16:26 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i73FHhe7000787; Tue, 3 Aug 2004 11:17:44 -0400 Message-ID: <410FAC48.3040400@intertwingly.net> Date: Tue, 03 Aug 2004 11:16:24 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: David Orchard , Atom-Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> In-Reply-To: <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tim Bray wrote: > On Aug 3, 2004, at 4:58 AM, Sam Ruby wrote: > >> There are other factors involved. Look at Georgic [1] "Too bad, I’m >> not changing the title". What would happen if Tim *did* change the >> title? Well the title is in the URI... from a locator perspective, >> this is not a big problem as you can set up redirection. From an >> identifier perspective, this represents a problem. > > No, at ongoing, the title of the article and its URI are 100% > decoupled. I change titles all the time without breaking URIs. The > fact that in that entry they're the same is a coincidence, look at some > others. The auto-generation of URIs from titles is a filthy web-hostile > practice that should be stopped. -Tim Perhaps a better way to put it is that they tend to be derived from the same common source - and that source is prone to error. On my weblog, the title and link are theoretically 100% decoupled too - as long as you don't consider the desire to pick a URI which contains some of the same elements as the title. In legal terms, I think this is referred to as an attractive nuisance[1]. -Sam Ruby [1] http://insurance.cch.com/rupps/attractive-nuisance-doctrine.htm From owner-atom-syntax@mail.imc.org Tue Aug 3 12:08:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17798 for ; Tue, 3 Aug 2004 12:08:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Fo0Fs073988; Tue, 3 Aug 2004 08:50:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Fo0hs073987; Tue, 3 Aug 2004 08:50:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Fnxol073981 for ; Tue, 3 Aug 2004 08:49:59 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail11.mac.com (webmail11-en1 [10.13.10.117]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i73Fo2fO021177; Tue, 3 Aug 2004 08:50:02 -0700 (PDT) Received: from webmail11 (localhost [127.0.0.1]) by webmail11.mac.com (8.12.6/8.12.2) with ESMTP id i73Fo2VI021796; Tue, 3 Aug 2004 08:50:02 -0700 (PDT) Message-ID: <13060801.1091548201912.JavaMail.dtcd@mac.com> Date: Tue, 03 Aug 2004 16:50:01 +0100 From: Graham Parks To: Sam Ruby Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Cc: atom-syntax@imc.org in-reply-to: <410EE6A7.30502@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <14290954.1091493822057.JavaMail.dtcd@mac.com> <410EE6A7.30502@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 Aug 2004, at 9:13 pm, Sam Ruby wrote: > Who would one detect "meant to be different but match after normalization"? From a validator point of view, if a feed contains two different entries with ids like "http://www.example.com/" and "http://www.example.com:80/", you can say to some software these are duplicate ids. Basically, publishers need to make sure every id is different enough from the last if they intend them to be different. But if they intend them to be the same, they still need to be character for character the same. That way all comparison methods work. Graham From owner-atom-syntax@mail.imc.org Tue Aug 3 12:09:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17895 for ; Tue, 3 Aug 2004 12:09:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Fv2v4074555; Tue, 3 Aug 2004 08:57:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Fv2Pb074554; Tue, 3 Aug 2004 08:57:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Fv1fK074546 for ; Tue, 3 Aug 2004 08:57:02 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 956E67C0F3; Tue, 3 Aug 2004 18:51:29 +0200 (CEST) To: "Sam Ruby" Cc: Atom-Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> Message-ID: Date: Tue, 03 Aug 2004 18:00:50 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <410F7DDB.6060200@intertwingly.net> User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 03 Aug 2004 07:58:19 -0400, Sam Ruby wrote: > Let people use the URI scheme that they want; simply state the contract > by which the URIs when used as ids must conform to. And since HTTP is > widely known, document at least one other scheme so that people can be > aware of the tradeoffs. I'm +1 on this, which is what I have tried to capture in PaceRecommendIdScheme[1]. ____ [1] -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Aug 3 12:38:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19822 for ; Tue, 3 Aug 2004 12:38:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GJwHM075887; Tue, 3 Aug 2004 09:19:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73GJwgC075886; Tue, 3 Aug 2004 09:19:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GJvR2075879 for ; Tue, 3 Aug 2004 09:19:58 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so173014rnk for ; Tue, 03 Aug 2004 09:19:58 -0700 (PDT) Received: by 10.38.81.54 with SMTP id e54mr440302rnb; Tue, 03 Aug 2004 09:19:58 -0700 (PDT) Message-ID: <14be96d304080309191e3af694@mail.gmail.com> Date: Tue, 3 Aug 2004 12:19:58 -0400 From: Mark Pilgrim To: Tim Bray Subject: Re: PaceBasicAtomID - maybe we're done Cc: Sam Ruby , Atom-Syntax In-Reply-To: <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 03 Aug 2004 07:56:42 -0700, Tim Bray wrote: > The auto-generation of URIs from titles is a filthy > web-hostile practice that should be stopped. -Tim Are you suggesting that Atom should contain spec text to recommend a URI structure for resources created by Atom-enabled applications? Does this have anything to do with Atom at all? If not, please consider a more appropriate venue for such passionate statements. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 3 12:39:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19886 for ; Tue, 3 Aug 2004 12:39:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GVRFf076650; Tue, 3 Aug 2004 09:31:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73GVRww076649; Tue, 3 Aug 2004 09:31:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GVQWV076643 for ; Tue, 3 Aug 2004 09:31:26 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i73GT753026118 for ; Tue, 3 Aug 2004 10:29:07 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1V003QVPWHCB@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 03 Aug 2004 10:31:29 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1V00C2SPWDE4@mail.sun.net> for atom-syntax@imc.org; Tue, 03 Aug 2004 10:31:28 -0600 (MDT) Date: Tue, 03 Aug 2004 09:31:47 -0700 From: Tim Bray Subject: Re: PaceBasicAtomID - maybe we're done In-reply-to: <14be96d304080309191e3af694@mail.gmail.com> To: Mark Pilgrim Cc: Sam Ruby , Atom-Syntax Message-id: <9D4EB080-E56A-11D8-B820-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> <14be96d304080309191e3af694@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 3, 2004, at 9:19 AM, Mark Pilgrim wrote: > Are you suggesting that Atom should contain spec text to recommend a > URI structure for resources created by Atom-enabled applications? I think it would be entirely appropriate for one of our drafts to point out the advantages of stable URIs since, on the evidence, a lot of the blogging infrastructure is unaware of them. A pointer to http://www.w3.org/TR/webarch/#URI-persistence would probably suffice. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 3 12:50:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20761 for ; Tue, 3 Aug 2004 12:50:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GdG4m077227; Tue, 3 Aug 2004 09:39:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73GdGfY077226; Tue, 3 Aug 2004 09:39:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GdFHO077214 for ; Tue, 3 Aug 2004 09:39:15 -0700 (PDT) (envelope-from jlpicard@us.ibm.com) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i73Gd9DD401734 for ; Tue, 3 Aug 2004 12:39:09 -0400 Received: from d03nm120.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i73Gd761375662 for ; Tue, 3 Aug 2004 10:39:09 -0600 Importance: Normal Subject: Introducing myself / Atom API Test Suite / Categories To: Atom-Syntax X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Craig Becker Date: Tue, 3 Aug 2004 11:28:56 -0500 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/03/2004 10:39:08 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE476DFCAC35A8f9e8a93df938690918c08BBE476DFCAC35A" Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0__=08BBE476DFCAC35A8f9e8a93df938690918c08BBE476DFCAC35A Content-type: text/plain; charset=US-ASCII Hello all, my name is Craig Becker and I will be working with Sam Ruby to build a conformance test suite for the Atom API[1]. I will most happily and cheerfully accept any suggestions, pointers, sample code, &c that anyone feels could be helpful in building this test suite. I've been doing a little work implementing the Atom API in WordPress, and this work has generated some questions, and I hope it will be okay if I toss them out here for discussion. For starters: has there been any discussion of how Atom will deal with Categories when posting to a blog? WordPress and other blog software will allow a blogger to define their own arbitrary Categories. How might a client query a blog to determine valid Categories? Craig [1] or, as Mark Pilgrim put it, I'm Sam's new "minion" :) Craig Becker, SWG Technology Center (512) 838-8068 Austin TX USA Internet: jlpicard@us.ibm.com http://dinosaur.austin.ibm.com/jlpicard/ "Remember, you can't put too much water in a nuclear reactor" --0__=08BBE476DFCAC35A8f9e8a93df938690918c08BBE476DFCAC35A Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hello all, my name is Craig Becker and I will be working with Sam Ruby
to build a conformance test suite for the Atom API[1].

I will most happily and cheerfully accept any suggestions, pointers, sample
code, &c that anyone feels could be helpful in building this test suite.

I've been doing a little work implementing the Atom API in WordPress, and
this work has generated some questions, and I hope it will be okay if I toss
them out here for discussion. For starters: has there been any discussion
of how Atom will deal with Categories when posting to a blog? WordPress
and other blog software will allow a blogger to define their own arbitrary
Categories. How might a client query a blog to determine valid Categories?

Craig

[1] or, as Mark Pilgrim put it, I'm Sam's new "minion" :)

Craig Becker, SWG Technology Center (512) 838-8068 Austin TX USA
Internet: jlpicard@us.ibm.com http://dinosaur.austin.ibm.com/jlpicard/

"Remember, you can't put too much water in a nuclear reactor"
--0__=08BBE476DFCAC35A8f9e8a93df938690918c08BBE476DFCAC35A-- From owner-atom-syntax@mail.imc.org Tue Aug 3 12:59:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21621 for ; Tue, 3 Aug 2004 12:59:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GlNte078245; Tue, 3 Aug 2004 09:47:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73GlNLY078244; Tue, 3 Aug 2004 09:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id i73GlMlA078234 for ; Tue, 3 Aug 2004 09:47:22 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 56647 messnum 2112371 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 3 Aug 2004 16:41:12 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail10.svc.cra.dublin.eircom.net (qp 56647) with SMTP; 3 Aug 2004 16:41:12 -0000 Message-ID: <410FC01A.4090907@dehora.net> Date: Tue, 03 Aug 2004 17:40:58 +0100 From: =?windows-1252?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Tim Bray CC: Sam Ruby , David Orchard , Atom-Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> In-Reply-To: <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > No, at ongoing, the title of the article and its URI are 100% > decoupled. I change titles all the time without breaking URIs. The > fact that in that entry they're the same is a coincidence, look at some > others. The auto-generation of URIs from titles is a filthy web-hostile > practice that should be stopped. -Tim Nonetheless, a marked improvement from "Cool URIs don't contain autoincrementing (probably from the database) integer keys" :) cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 3 13:03:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22001 for ; Tue, 3 Aug 2004 13:03:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GrrWi078725; Tue, 3 Aug 2004 09:53:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Grrcd078724; Tue, 3 Aug 2004 09:53:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (air643.startdedicated.com [69.64.38.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73GrqpU078716 for ; Tue, 3 Aug 2004 09:53:53 -0700 (PDT) (envelope-from david@blojsom.com) Received: (qmail 23614 invoked from network); 3 Aug 2004 16:43:37 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 3 Aug 2004 16:43:37 -0000 Received: from air643.startdedicated.com (air643.startdedicated.com [69.64.38.51]) by webmail.blojsom.com (IMP) with HTTP for ; Tue, 3 Aug 2004 12:43:37 -0400 Message-ID: <1091551417.410fc0b9e89e7@webmail.blojsom.com> Date: Tue, 3 Aug 2004 12:43:37 -0400 From: David Czarnecki To: Atom-Syntax Subject: Re: Introducing myself / Atom API Test Suite / Categories References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 69.64.38.51 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > I've been doing a little work implementing the Atom API in WordPress, and > this work has generated some questions, and I hope it will be okay if I > toss > them out here for discussion. For starters: has there been any discussion > of how Atom will deal with Categories when posting to a blog? WordPress > and other blog software will allow a blogger to define their own arbitrary > Categories. How might a client query a blog to determine valid Categories? The SixApart/TypePad folks have done it via a CategoryURI. A GET request can be sent to the CategoryURI to query the valid categories. @see - http://www.sixapart.com/developers/atom/typepad/ -David > > Craig > > [1] or, as Mark Pilgrim put it, I'm Sam's new "minion" :) > > Craig Becker, SWG Technology Center (512) 838-8068 Austin TX USA > Internet: jlpicard@us.ibm.com > http://dinosaur.austin.ibm.com/jlpicard/ > > "Remember, you can't put too much water in a nuclear reactor" From owner-atom-syntax@mail.imc.org Tue Aug 3 13:09:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22377 for ; Tue, 3 Aug 2004 13:09:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Gpk4W078593; Tue, 3 Aug 2004 09:51:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73Gpk2W078592; Tue, 3 Aug 2004 09:51:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Gpjtp078586 for ; Tue, 3 Aug 2004 09:51:45 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i73Gr7AQ005348; Tue, 3 Aug 2004 12:53:07 -0400 Message-ID: <410FC2A4.5080301@intertwingly.net> Date: Tue, 03 Aug 2004 12:51:48 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: atom-syntax@imc.org Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) References: <14290954.1091493822057.JavaMail.dtcd@mac.com> <410EE6A7.30502@intertwingly.net> <13060801.1091548201912.JavaMail.dtcd@mac.com> In-Reply-To: <13060801.1091548201912.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > On 2 Aug 2004, at 9:13 pm, Sam Ruby wrote: > >> Who would one detect "meant to be different but match after >> normalization"? > >> From a validator point of view, if a feed contains two different >> entries with ids like "http://www.example.com/" and >> "http://www.example.com:80/", you can say to some software these >> are duplicate ids. Basically, publishers need to make sure every id >> is different enough from the last if they intend them to be >> different. But if they intend them to be the same, they still need >> to be character for character the same. That way all comparison >> methods work. Pubsub plans to republish items from other sources. They intend to be the same. How does the feedvalidator verify this? We are getting into areas of opinion. Areas where reasonable people can reasonably disagree. Certainly the feedvalidator can't verify intent - or even if pubsub considered the original ids at all or simply elected to regenerate identifiers anew. Given that spiders are prone to aggresively normalize, and that the results of spidering is likely to be republished, I would like to do one of two things: 1) Either nail down precisely the comparison method so that implementations that do otherwise are clearly wrong. 2) Nail down the canonicalization rules so that implementation methods that vary within those bounds - and only within those bounds - will interoperate. Spending a few minutes with .Net's Sytem.URI class, and in particular it's constructor, .ToString() and .Equals() methods, indicate to me that even non-spiders will tend to normalize; so the second approach seems the most prudent. Console.WriteLine(new Uri("HTTP://EXAMPLE.COM:80").ToString()); => http://example.com/ Console.WriteLine(new Uri("HTTP://EXAMPLE.COM/%7ESmith").ToString()); => http://example.com/~Smith - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 3 13:33:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24414 for ; Tue, 3 Aug 2004 13:33:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73HHM2g080512; Tue, 3 Aug 2004 10:17:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73HHMLH080511; Tue, 3 Aug 2004 10:17:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73HHLWk080497 for ; Tue, 3 Aug 2004 10:17:21 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 7493F7C0F3; Tue, 3 Aug 2004 20:11:54 +0200 (CEST) To: "Tim Bray" , "Mark Pilgrim" Cc: "Sam Ruby" , Atom-Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> <14be96d304080309191e3af694@mail.gmail.com> <9D4EB080-E56A-11D8-B820-000A95A51C9E@sun.com> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 03 Aug 2004 19:21:36 +0200 In-Reply-To: <9D4EB080-E56A-11D8-B820-000A95A51C9E@sun.com> User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 03 Aug 2004 09:31:47 -0700, Tim Bray wrote: > I think it would be entirely appropriate for one of our drafts to point > out the advantages of stable URIs since, on the evidence, a lot of the > blogging infrastructure is unaware of them. A pointer to > http://www.w3.org/TR/webarch/#URI-persistence would probably suffice. Reference added to PaceRecommendIdScheme. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Aug 3 14:28:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29623 for ; Tue, 3 Aug 2004 14:28:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73ICZh7085405; Tue, 3 Aug 2004 11:12:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73ICZEh085404; Tue, 3 Aug 2004 11:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i73ICYcC085390 for ; Tue, 3 Aug 2004 11:12:34 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 11546 invoked from network); 3 Aug 2004 18:15:07 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 3 Aug 2004 18:15:07 -0000 Subject: Re: PaceBasicAtomID - maybe we're done From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Atom syntax In-Reply-To: <9D4EB080-E56A-11D8-B820-000A95A51C9E@sun.com> References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> <14be96d304080309191e3af694@mail.gmail.com> <9D4EB080-E56A-11D8-B820-000A95A51C9E@sun.com> Content-Type: text/plain Message-Id: <1091556771.2056.33.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 03 Aug 2004 19:12:52 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-03 at 17:31, Tim Bray wrote: > On Aug 3, 2004, at 9:19 AM, Mark Pilgrim wrote: > > > Are you suggesting that Atom should contain spec text to recommend a > > URI structure for resources created by Atom-enabled applications? > > I think it would be entirely appropriate for one of our drafts to point > out the advantages of stable URIs since, on the evidence, a lot of the > blogging infrastructure is unaware of them. A pointer to > http://www.w3.org/TR/webarch/#URI-persistence would probably suffice. +1, with rationale please? How to hack it if you do have a domain (whatever Tim means by separating a title from its uri) How to hack it if you don't hold a domain name. And why its important/ What happens if you ignore this bit etc. I still haven't heard a compelling rationale for 'making my ID's different from yours' As for testing it? Forget it. 24 hour challenge. Here's a URI (you make it up). tell me if its unique in TimBL's net? I guess even TAG would scratch their heads over that. -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Tue Aug 3 14:32:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00067 for ; Tue, 3 Aug 2004 14:32:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73IKSRd085855; Tue, 3 Aug 2004 11:20:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73IKSQA085854; Tue, 3 Aug 2004 11:20:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73IKROt085848 for ; Tue, 3 Aug 2004 11:20:28 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 7FE357C0F3; Tue, 3 Aug 2004 21:15:00 +0200 (CEST) Date: Tue, 03 Aug 2004 20:24:55 +0200 To: "Bjoern Hoehrmann" Subject: Re: PaceRecommendIdScheme Cc: Atom-Syntax References: <41300074.614590614@smtp.bjoern.hoehrmann.de> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <41300074.614590614@smtp.bjoern.hoehrmann.de> User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 31 Jul 2004 23:41:14 +0200, Bjoern Hoehrmann wrote: > If the element content identifies the feed it cannot change. Some entity > might change the element content, but it would then be a different feed. > While it might be undesirable to have different identifiers for feeds > commonly perceived as equal, I don't think it is reasonable to make that > a conformance criteria. It is not possible to write software that tests > whether it changed with perfect reliability, for example. Does this go for entries as well? If not, what differs entries from feeds in that respect? > It is also not clear to me when two feeds are considered equivalent, > which would be necessary to determine whether the id changed. I'm not sure about that either. To be honest, I don't see a lot of reasons to have an identifier for atom:feed, unless it in some wierd way represents an atom:entry. > If the author, title, tagline, and primary subject of the feed are > changed, can it still be the same feed? Not imho, no. > I also see valid reasons to "change" the id, e.g. if the old id refers to > a DNS name which is no longer controlled by the feed author. This goes for entries as well. A common policy should be maintained for both, regardless of what that policy is. > The same applies to uniqueness. While it might be undesirable if one > identifier identifies different feeds, I do not think this requirement > is reasonable. It would mean that I can publish an Atom document with > tag:diveintomark.org,2001-07-29:/ it would render Mark's feed > non-conforming. I do not think it should. The non-conforming feed would of course be yours, but I get your point. This is not easy to test against either. The difference between entries and feeds here, is that while the sam entry is likely to show up in many different feeds, this doesn't apply to feeds. > It would be better to include an informational note that publishers > should take all reasonable steps to maintain the identifier. Any idea how to note this? > We can also specify that entry s MUST be locally unique, and that > intermediaries MUST NOT change s, etc., but we should stick to > things that are at least reliably human-testable. Probably good enough, since I don't see a point in the atom:feed/atom:id anyway. >> The URI scheme of atom:id MAY be a dereferencable URL scheme (like >> HTTP), >> but MUST NOT be expected to be one. > > I do not understand what beeing expected to be a dereferencable URL > scheme means in this context. Consumers shouldn't expect atom:id to be dereferencable, since not all URI's are. It's also imho not a good practice to have dereferencable ID's, since dereferencability often leads to mutable ID's, since objects on the web are moved all the time. Producers should also not expect consumers to dereference their atom:id's, and thus isn't there much to gain from using HTTP URI's. Recommending another ID scheme also makes HTTP URI's less common, which hopefully will help generating more stable ID's in the future. > Maybe you want to state that Atom software must not attempt to > dereference the identifier? I don't care if they attempt to do it, really. The point is that atom:id is just a URI, which may or may not be dereferencable. > What is the use case for empty elements? Is «nothing» a valid URI? The text states that atom:id MUST be a URI. > I think it is okay to prohibe relative references, but I think fragment > identifiers should be allowed. I can't see that the text prohibits people from using fragment identifiers. Should I write something explicit about that? > I have no idea what the part about post-processing could mean, > could you elaborate? Having to resolve the base URI and with whatever method needed, concatenate this with the atom:id if it is relative, is (post) processing of the identifier. Or pre-processing. That depends on how you see it. The ID should at least not have to be fed through several layers of algorithmic mumbo jumbo to be fully qualified and ready to be compared with other ID's, however we express this. > I don't think it is a good idea to duplicate all the content, it makes > it rather difficult to learn how atom:id differs for feeds and entries. Good point. I'll create a new «common construct» that explains about identifiers. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Aug 3 15:26:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05462 for ; Tue, 3 Aug 2004 15:26:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73JHJxx091629; Tue, 3 Aug 2004 12:17:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73JHJ1e091628; Tue, 3 Aug 2004 12:17:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73JHIMp091617 for ; Tue, 3 Aug 2004 12:17:18 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i73JHG53019540 for ; Tue, 3 Aug 2004 14:17:16 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i73JHGeF019536; Tue, 3 Aug 2004 14:17:16 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom syntax Subject: Re: PaceBasicAtomID - maybe we're done References: <32D5845A745BFB429CBDBADA57CD41AF09569AAB@ussjex01.amer.bea.com> <410F7DDB.6060200@intertwingly.net> <54C0299E-E55D-11D8-B820-000A95A51C9E@sun.com> <14be96d304080309191e3af694@mail.gmail.com> <9D4EB080-E56A-11D8-B820-000A95A51C9E@sun.com> <1091556771.2056.33.camel@homer> From: Ken MacLeod Date: 03 Aug 2004 14:17:15 -0500 In-Reply-To: <1091556771.2056.33.camel@homer> Message-ID: Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Pawson writes: > On Tue, 2004-08-03 at 17:31, Tim Bray wrote: > > On Aug 3, 2004, at 9:19 AM, Mark Pilgrim wrote: > > > > > Are you suggesting that Atom should contain spec text to recommend a > > > URI structure for resources created by Atom-enabled applications? > > > > I think it would be entirely appropriate for one of our drafts to > > point out the advantages of stable URIs since, on the evidence, a > > lot of the blogging infrastructure is unaware of them. A pointer > > to http://www.w3.org/TR/webarch/#URI-persistence would probably > > suffice. > And why its important/ > What happens if you ignore this bit > etc. This is important. I suggested some test case for this for the publishing side[1], but there should also be spec text and tests for the consumer side as well. > I still haven't heard a compelling rationale for 'making my ID's > different from yours' 1) republishers will aggregate entries from multiple sources into common feeds. It's easier to distinguish entries based on their unique identifier than the tuple of the origin feed and a "local" entry identifier. Essentially, that's still a global identifier. 2) in the near future (maybe not Atom 1.0, but there's been proposals for it) entries will make references to entries from other sites. Those references will be made based on the URI. If two sites don't have unique IDs for their entries, the references will be garbled. > As for testing it? Forget it. > 24 hour challenge. > Here's a URI (you make it up). tell me if its unique in TimBL's net? > I guess even TAG would scratch their heads over that. You're correct. We can only state the properties for uniqueness, suggest best practices for creating them, and "test in the large" for collisions, and hope for the best. Without an alternate proposal on the table to compare it to, I don't see that as a fatal flaw. -- Ken [1] http://imc.org/atom-syntax/mail-archive/msg07923.html From owner-atom-syntax@mail.imc.org Tue Aug 3 16:36:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10030 for ; Tue, 3 Aug 2004 16:36:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73KR0iu097946; Tue, 3 Aug 2004 13:27:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73KR0CB097945; Tue, 3 Aug 2004 13:27:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73KQxdt097938 for ; Tue, 3 Aug 2004 13:26:59 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i73KR1il028537 for ; Tue, 3 Aug 2004 14:27:02 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1W00FAQ0T1IV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 03 Aug 2004 14:27:01 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1W00K1S0T03Q@mail.sun.net> for atom-syntax@imc.org; Tue, 03 Aug 2004 14:27:01 -0600 (MDT) Date: Tue, 03 Aug 2004 13:27:22 -0700 From: Tim Bray Subject: Work Queue Rotation #5 To: Atom-Syntax Syntax Message-id: <865CD8BB-E58B-11D8-B820-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Here's where I think are on the current work items from http://www.intertwingly.net/wiki/pie/AtomPubIssuesList - as always, the traffic volume is high & nonlinear and I may have misread on one or more of these, feel free to disagree. 1. PaceAutoDisco I think we have consensus to turn MarkP's draft (http://diveintomark.org/rfc/draft-pilgrim-atom-autodiscovery-02.html) into a committee draft with Mark as editor. There was some desultory discussion of rolling it into one of the existing drafts, but I didn't hear much cheering. Paul & Mark should talk about mechanics & process. I guess (on the basis of little discussion) that both the format and protocol drafts should informatively reference the new draft. I think we can mark this "accepted" in principle and give the editors a fairly free hand in how & where to work the language in. 2. PaceFeedEquivalence I don't think we're done with discussion about what goes in atom:id, but whatever happens with that, it's clear that Atom implementors will end up doing some URI comparisons, and that wherever this comes up in our drafts, we (a) bless the use of codepoint-by-codepoint comparisons, (b) acknowledge that real-software often goes further, and (c) in the case that RFC2396bis gets finished before Atom, point informatively to its section 6, and (d) write language into the specifications encouraging the canonicalization of URIs, I see little dissent to Sam Ruby's suggestion at http://www.intertwingly.net/wiki/pie/PaceCanonicalIds, but I'm aware of at least one further proposal incoming on atom:id so let's put Sam's Pace into "Need To Revisit". However, I don't think the language in the actual PaceFeedEquivalence is what we ended up with, so let's mark this "closed". 3. PaceLinkReflection I was apparently the only person pushing back, and I was OK with Sam's reformulation at http://imc.org/atom-syntax/mail-archive/msg08137.html, and nobody else seemed unhappy, so let's mark this "accepted" on the basis of Sam's language. 4. PaceResource and PaceSimpleResourcePosting I proposed a way forward here: http://imc.org/atom-syntax/mail-archive/msg08045.html, which involved a bit of editorial discretion, the only real pushback was from Ken MacLeod (http://imc.org/atom-syntax/mail-archive/msg08052.html) but I think his issue was around the whole PUT/DELETE question which is I think separable from the Atom Protocol supporting a simple way to POST non-textual resources. Ken separately (http://imc.org/atom-syntax/mail-archive/msg08058.html) suggested withdrawing PaceNonEntryResources and I saw no dissent. Sam can now fire up his mighty Issues-List engine and re-clog our inbaskets... -Tim From owner-atom-syntax@mail.imc.org Tue Aug 3 17:31:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13773 for ; Tue, 3 Aug 2004 17:31:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LLqX8001679; Tue, 3 Aug 2004 14:21:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73LLqRt001678; Tue, 3 Aug 2004 14:21:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-133-31.ietf60.ietf.org [130.129.133.31]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LLpXX001671 for ; Tue, 3 Aug 2004 14:21:52 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 3 Aug 2004 14:22:02 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: A simpler proposal: PaceAtomIDAsString Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. The earlier thread on atom:id made it clear that people really, really want to compare things consistently, and that using URIs might get in the way of that. Thus, I have made a simplifying proposal at . It explicitly allows URIs for people who want URIs, and allows plain text for the rest of us. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 3 17:31:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13774 for ; Tue, 3 Aug 2004 17:31:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LPkm2002152; Tue, 3 Aug 2004 14:25:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73LPkIc002151; Tue, 3 Aug 2004 14:25:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i73LPj1P002111 for ; Tue, 3 Aug 2004 14:25:46 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 4734 invoked by uid 65534); 3 Aug 2004 21:25:38 -0000 Received: from dsl-082-082-072-206.arcor-ip.net (EHLO localhost) (82.82.72.206) by mail.gmx.net (mp003) with SMTP; 03 Aug 2004 23:25:38 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: Atom-Syntax Subject: Re: PaceRecommendIdScheme Date: Tue, 03 Aug 2004 23:25:30 +0200 Message-ID: <412efd33.875902140@smtp.bjoern.hoehrmann.de> References: <41300074.614590614@smtp.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Asbjørn Ulsberg wrote: >> If the element content identifies the feed it cannot change. Some entity >> might change the element content, but it would then be a different feed. >> While it might be undesirable to have different identifiers for feeds >> commonly perceived as equal, I don't think it is reasonable to make that >> a conformance criteria. It is not possible to write software that tests >> whether it changed with perfect reliability, for example. > >Does this go for entries as well? Most of it, yes. >> It would be better to include an informational note that publishers >> should take all reasonable steps to maintain the identifier. > >Any idea how to note this? Well, something like Sections preceded by "Note:" are informational... ... Note: Publishers should take all reasonable steps to maintain the identifier $rationale $best-practise-to-achieve-that ... >> I do not understand what beeing expected to be a dereferencable URL >> scheme means in this context. > >Consumers shouldn't expect atom:id to be dereferencable, since not all >URI's are. It's also imho not a good practice to have dereferencable ID's, >since dereferencability often leads to mutable ID's, since objects on the >web are moved all the time. Well, yes, but what would it mean for software to expect something to be dereferencable? They do if they attempt to dereference it or if it provides means to the user to trigger such an attempt. If that is all you mean, it would be better to state this more clearly. >> What is the use case for empty elements? > >Is «nothing» a valid URI? The text states that atom:id MUST be a URI. It actually states The content of this element, when present, MUST be a URI. If the content is not present, the element is empty. If that is not allowed, then noting "when present" is pointless and misleading. And yes, a string with a length of zero is a legal URI, but not a legal absoluteURI. >I can't see that the text prohibits people from using fragment >identifiers. Should I write something explicit about that? There are many people confused by what the terms "URI", "URI Reference" etc. mean, some people think "URI" may have a fragment identifier, some disagree, some people think "URI" always starts with a scheme, some think "URI" allows relative and absolute forms, etc., see http://www.w3.org/mid/41aa64e7.1905102963@smtp.bjoern.hoehrmann.de for a related discussion. (Note that my text did not contain %f6, W3C's broken mailing list archive software changed the text). As far as I am concerned, "URI" can be both relative and absolute and the only difference between "URI" and "URI Reference" is that the latter allowes a fragment identifier. So your text prohibes fragment identifiers. >> I have no idea what the part about post-processing could mean, >> could you elaborate? > >Having to resolve the base URI and with whatever method needed, >concatenate this with the atom:id if it is relative, is (post) processing >of the identifier. Or pre-processing. That depends on how you see it. The >ID should at least not have to be fed through several layers of >algorithmic mumbo jumbo to be fully qualified and ready to be compared >with other ID's, however we express this. Since it must not relative, it seems to me that it would always be "fully qualified", I certainly don't see which kind of processing could make an identifier more "persistent" or "universally unique" without changing the identifier. Could you give a counter example? If not then it seems that the text about post-processing should be removed. From owner-atom-syntax@mail.imc.org Tue Aug 3 17:50:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14895 for ; Tue, 3 Aug 2004 17:50:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LfWtV003229; Tue, 3 Aug 2004 14:41:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73LfWIa003228; Tue, 3 Aug 2004 14:41:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73LfVuf003218; Tue, 3 Aug 2004 14:41:32 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id B91C97C0F3; Wed, 4 Aug 2004 00:36:01 +0200 (CEST) To: "Paul Hoffman / IMC" Cc: Atom-Syntax Subject: Re: A simpler proposal: PaceAtomIDAsString References: Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 03 Aug 2004 23:45:37 +0200 In-Reply-To: User-Agent: Opera M2/7.52 (Win32, build 3834) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 3 Aug 2004 14:22:02 -0700, Paul Hoffman / IMC wrote: > . Hm. I actually thought you were joking when you proposed this the first time. :-) Anyway: +1! -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Aug 3 18:22:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17874 for ; Tue, 3 Aug 2004 18:22:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73MExvn005733; Tue, 3 Aug 2004 15:14:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73MExDN005732; Tue, 3 Aug 2004 15:14:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i73MEwmF005719 for ; Tue, 3 Aug 2004 15:14:58 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040803221459.7495.qmail@web41209.mail.yahoo.com> Received: from [207.46.238.143] by web41209.mail.yahoo.com via HTTP; Tue, 03 Aug 2004 15:14:58 PDT Date: Tue, 3 Aug 2004 15:14:58 -0700 (PDT) From: Dare Obasanjo Subject: Re: A simpler proposal: PaceAtomIDAsString To: Paul Hoffman / IMC , Atom WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Paul Hoffman / IMC wrote: > > Greetings again. The earlier thread on atom:id made > it clear that > people really, really want to compare things > consistently, and that > using URIs might get in the way of that. Thus, I > have made a > simplifying proposal at > . > > It explicitly allows URIs for people who want URIs, > and allows plain > text for the rest of us. Where are the guidelines that make it so that people can create globally unique identifiers using arbitrary strings? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 3 18:58:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19905 for ; Tue, 3 Aug 2004 18:58:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73MqCi1008252; Tue, 3 Aug 2004 15:52:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73MqCD4008251; Tue, 3 Aug 2004 15:52:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-129-231.ietf60.ietf.org [130.129.129.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73Mq9gY008230; Tue, 3 Aug 2004 15:52:10 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20040803221459.7495.qmail@web41209.mail.yahoo.com> References: <20040803221459.7495.qmail@web41209.mail.yahoo.com> Date: Tue, 3 Aug 2004 15:52:20 -0700 To: Dare Obasanjo , Atom WG From: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:14 PM -0700 8/3/04, Dare Obasanjo wrote: >Where are the guidelines that make it so that people >can create globally unique identifiers using arbitrary >strings? Um, in the same place as the guidelines that make it so that people can create globally unique identifiers using URIs? That is, they are the same. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 3 19:26:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21267 for ; Tue, 3 Aug 2004 19:26:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73NIHex010634; Tue, 3 Aug 2004 16:18:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73NIHaI010633; Tue, 3 Aug 2004 16:18:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73NIHIi010620; Tue, 3 Aug 2004 16:18:17 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail15.mac.com (webmail15-en1 [10.13.10.141]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i73NIMOo022892; Tue, 3 Aug 2004 16:18:22 -0700 (PDT) Received: from webmail15 (localhost [127.0.0.1]) by webmail15.mac.com (8.12.6/8.12.2) with ESMTP id i73NIMq1006756; Tue, 3 Aug 2004 16:18:22 -0700 (PDT) Message-ID: <12697117.1091575101994.JavaMail.dtcd@mac.com> Date: Wed, 04 Aug 2004 00:18:21 +0100 From: Graham Parks To: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Cc: atom-syntax@imc.org in-reply-to: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday, August 03, 2004, at 10:32PM, Paul Hoffman / IMC wrote: >Greetings again. The earlier thread on atom:id made it clear that >people really, really want to compare things consistently, and that >using URIs might get in the way of that. Thus, I have made a >simplifying proposal at >. I agree 100% that the id should always be treated as a string. My problem is that with no rules on format, a publisher can only guessing that your identifier is unique, which isn't a problem with say, tag URIs. eg Gizmodo's GUIDs look like: 18819@http://www.gizmodo.com/ Yes, it's unlikely anyone else will use a GUID like that, but it's very hard to be sure. Graham From owner-atom-syntax@mail.imc.org Tue Aug 3 19:41:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22234 for ; Tue, 3 Aug 2004 19:41:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i73NUr2S011635; Tue, 3 Aug 2004 16:30:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i73NUrcW011634; Tue, 3 Aug 2004 16:30:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i73NUq17011621 for ; Tue, 3 Aug 2004 16:30:52 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 22405 invoked by uid 65534); 3 Aug 2004 23:30:51 -0000 Received: from dsl-082-082-072-206.arcor-ip.net (EHLO localhost) (82.82.72.206) by mail.gmx.net (mp009) with SMTP; 04 Aug 2004 01:30:51 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Paul Hoffman / IMC Cc: Atom WG Subject: Re: A simpler proposal: PaceAtomIDAsString Date: Wed, 04 Aug 2004 01:30:43 +0200 Message-ID: <41341760.882602775@smtp.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Paul Hoffman / IMC wrote: >Greetings again. The earlier thread on atom:id made it clear that >people really, really want to compare things consistently, and that >using URIs might get in the way of that. Thus, I have made a >simplifying proposal at >. Hmm, it would make more sense to me to specify that the content must be for example the uc(md5_hex()) of some reasonably unique data and that implementations must not change the id without the user's consent, specifically not if [common cases]. That would avoid confusion about normalizing, resolving, dereferencing, comparing, ... the id, which scheme to choose, how to structure it, etc. while still providing the necessary functionality. It would certainly yield in duplicate IDs and there will still be authors and implementations that do not generate proper IDs, but as far as I can see implementations will have to deal with that anyway. Your proposal just obfuscates the issue as common practise will likely be to use URIs anyway, which would likely yield in all the problems we have when the spec says it is a more special kind of string. From owner-atom-syntax@mail.imc.org Tue Aug 3 20:20:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24940 for ; Tue, 3 Aug 2004 20:20:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740Bh37013795; Tue, 3 Aug 2004 17:11:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i740BhwX013793; Tue, 3 Aug 2004 17:11:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id i740Bggf013774 for ; Tue, 3 Aug 2004 17:11:43 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 71619 messnum 374819 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 4 Aug 2004 00:11:42 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail05.svc.cra.dublin.eircom.net (qp 71619) with SMTP; 4 Aug 2004 00:11:42 -0000 Message-ID: <411029B8.2070704@dehora.net> Date: Wed, 04 Aug 2004 01:11:36 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom WG Subject: Re: A simpler proposal: PaceAtomIDAsString References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > Greetings again. The earlier thread on atom:id made it clear that people > really, really want to compare things consistently, and that using URIs > might get in the way of that. Thus, I have made a simplifying proposal > at . > It explicitly allows URIs for people who want URIs, and allows plain > text for the rest of us. According to the pace, it's not plain text for the rest of us, it's Unicode for the rest of us. If the comparison rules are to be character based over Unicode, that would suggest the Unicode encoding must also be specified so we know how many bytes are being used per character and so on. A 'string of Unicode characters' isn't sufficient by itself. Perhaps the Pace is using "character" in a non-Unicode sense (if so, that's confusing). If the intention is really to compare on Unicode characters/codepoints independent of the encoding scheme (ie along the lines of some kind of Unicode 'Infoset'), that needs to be said - it's certainly not plain text anymore. But: "Even if a particular atom:id instance looks like a URI, it SHOULD NOT be treated as one." doesn't seem consistent with the idea that we can have URIs if we want. The pace is saying (to me) something along these lines "if it looks like a HTTP URL you shouldn't run GET on it; if it looks like a NewsML URI you shouldn't infer from the versioning bits". We have experience that suggests people will not be able to oblige themselves to this kind of constraint. IMO it should be struck. Generally I'm concerned that we will use URI scheme structures to generate unique keys (they're handy for that) and thus end up with Unicode strings that look like URIs but are not supposed to be treated as URIs, ever where those URIs have comparison and normalization rules. I believe this is maximally surprising. May I suggest this wording for the time being: " The "atom:id" element's content conveys a permanent, globally unique identifier for the feed. It MUST NOT change over time, even if the feed is relocated. An atom:head element MAY contain an atom:id element, but MUST NOT contain more than one. The content of this element, when present, MUST be a string of Unicode characters encoded as UTF-8. When atom:id elements are compared, they MUST be compared on a character-by-character basis. It is not a goal that atom:id be usable for retrieval of information. Historically, in syndication feeds, the detection of duplicates has been error-prone because of failure to assign identifiers which are globally unique and stable. Identifiers have been observed to change when a feed moved hosts or when an entry was reassigned to a different category or its title was edited. The management of globally unique and immutable identifiers requires prior planning and extra effort, but this is more than justified by the benefits of robust duplicate detection. " Of course this begs the question - what if the Atom is encoded as UTF-16? In all seriousness, perhaps I just don't understand the pace. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 3 20:51:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27180 for ; Tue, 3 Aug 2004 20:51:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740dlp7015959; Tue, 3 Aug 2004 17:39:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i740dlhB015958; Tue, 3 Aug 2004 17:39:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740dc46015948 for ; Tue, 3 Aug 2004 17:39:38 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i740bK53015202 for ; Tue, 3 Aug 2004 18:37:20 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1W00KD7CI77K@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 03 Aug 2004 18:39:44 -0600 (MDT) Received: from [192.168.1.15] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1W003XGCI7L2@mail.sun.net> for atom-syntax@imc.org; Tue, 03 Aug 2004 18:39:43 -0600 (MDT) Date: Tue, 03 Aug 2004 17:40:04 -0700 From: Tim Bray Subject: Re: A simpler proposal: PaceAtomIDAsString In-reply-to: <411029B8.2070704@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Atom WG Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <411029B8.2070704@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i740dk46015953 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Aug 3, 2004, at 5:11 PM, Bill de hÓra wrote: > According to the pace, it's not plain text for the rest of us, it's > Unicode for the rest of us. If the comparison rules are to be > character based over Unicode, that would suggest the Unicode encoding > must also be specified so we know how many bytes are being used per > character and so on. A 'string of Unicode characters' isn't sufficient > by itself. All your other points aside, yes it is sufficient. This is appearing in an Atom feed which is an XML document, right? In an XML document, element content or attribute value can contain any legal XML character (a generous subset of Unicode)... what encoding the XML document is in is an orthogonal issue. [Not commenting on the proposal itself, just saying that this particular criticism is off-base] --Tim From owner-atom-syntax@mail.imc.org Tue Aug 3 21:20:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28988 for ; Tue, 3 Aug 2004 21:20:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i741CKep019186; Tue, 3 Aug 2004 18:12:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i741CKbS019185; Tue, 3 Aug 2004 18:12:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i741CJQH019148 for ; Tue, 3 Aug 2004 18:12:19 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i741CK53023322 for ; Tue, 3 Aug 2004 20:12:20 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i741CJfW023318; Tue, 3 Aug 2004 20:12:19 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom WG Subject: Re: A simpler proposal: PaceAtomIDAsString References: From: Ken MacLeod Date: 03 Aug 2004 20:12:19 -0500 In-Reply-To: Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman / IMC writes: > Greetings again. The earlier thread on atom:id made it clear that > people really, really want to compare things consistently, and that > using URIs might get in the way of that. Thus, I have made a > simplifying proposal at > . > > It explicitly allows URIs for people who want URIs, and allows plain > text for the rest of us. We'll probably need to make sure we can create links to these "Atom string IDs" that are different than URI links: -- Ken From owner-atom-syntax@mail.imc.org Tue Aug 3 21:22:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29154 for ; Tue, 3 Aug 2004 21:22:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i741FAXG019800; Tue, 3 Aug 2004 18:15:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i741FArV019799; Tue, 3 Aug 2004 18:15:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i741F925019772 for ; Tue, 3 Aug 2004 18:15:09 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 3968 messnum 15263605 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 4 Aug 2004 01:10:05 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail11.svc.cra.dublin.eircom.net (qp 3968) with SMTP; 4 Aug 2004 01:10:05 -0000 Message-ID: <41103767.1000105@dehora.net> Date: Wed, 04 Aug 2004 02:09:59 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Tim Bray CC: Atom WG Subject: Re: A simpler proposal: PaceAtomIDAsString References: <411029B8.2070704@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tim Bray wrote: > > On Aug 3, 2004, at 5:11 PM, Bill de hÓra wrote: > >> According to the pace, it's not plain text for the rest of us, it's >> Unicode for the rest of us. If the comparison rules are to be >> character based over Unicode, that would suggest the Unicode encoding >> must also be specified so we know how many bytes are being used per >> character and so on. A 'string of Unicode characters' isn't sufficient >> by itself. > > > All your other points aside, yes it is sufficient. This is appearing in > an Atom feed which is an XML document, right? In an XML document, > element content or attribute value can contain any legal XML character > (a generous subset of Unicode)... what encoding the XML document is in > is an orthogonal issue. I don't see that. The pace seems to want to bring up Unicode character compares sans encodings, but it's being discussed in the context of plain text, it says URIs aren't to be treated URIs, but it's being discussed in the context that you can have your URIs if you want. And now we're talking about the legal range of XML characters in element content! If it's the case that you're right (encoding has nothing to do with atom:id comparison), why don't we say something around XML characters directly instead of Unicode directly - then we can talk about 'XML plain text'. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 3 21:49:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00594 for ; Tue, 3 Aug 2004 21:49:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i741jHGN022998; Tue, 3 Aug 2004 18:45:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i741jH7O022997; Tue, 3 Aug 2004 18:45:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-129-231.ietf60.ietf.org [130.129.129.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i741jFtZ022991 for ; Tue, 3 Aug 2004 18:45:16 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> References: <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> Date: Tue, 3 Aug 2004 18:44:13 -0700 To: atom-syntax@imc.org From: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 12:18 AM +0100 8/4/04, Graham Parks wrote: >I agree 100% that the id should always be treated as a string. My >problem is that with no rules on format, a publisher can only >guessing that your identifier is unique, which isn't a problem with >say, tag URIs. As has been said on this list before, publishers are "only guessing" that for any ID, including one that is a tag: URI. At 1:30 AM +0200 8/4/04, Bjoern Hoehrmann wrote: >Hmm, it would make more sense to me to specify that the content must >be for example the uc(md5_hex()) of some reasonably unique data That's good if you want opaque identifiers, but I haven't heard any need (or even desire!) for those so far. > and >that implementations must not change the id without the user's consent, >specifically not if [common cases]. That wording would be true for any atom:id proposal. But it's kind of obvious, isn't it? Do we really need to state it? >Your proposal just obfuscates the issue as common >practise will likely be to use URIs anyway, which would likely yield >in all the problems we have when the spec says it is a more special >kind of string. I'm not sure why you think it will be common practice. It's easy to do the right thing here and munge together a DNS name, a time, and a random string. At 1:11 AM +0100 8/4/04, Bill de hÓra wrote: >According to the pace, it's not plain text for the rest of us, it's >Unicode for the rest of us. Those are *identical*. > If the comparison rules are to be character based over Unicode, >that would suggest the Unicode encoding must also be specified so we >know how many bytes are being used per character and so on. Nope, exactly wrong. It is character-by-character, not byte-by-byte. >But: > >"Even if a particular atom:id instance looks like a URI, it SHOULD >NOT be treated as one." > >doesn't seem consistent with the idea that we can have URIs if we >want. The pace is saying (to me) something along these lines "if it >looks like a HTTP URL you shouldn't run GET on it; if it looks like >a NewsML URI you shouldn't infer from the versioning bits". Correct. > We have experience that suggests people will not be able to oblige >themselves to this kind of constraint. IMO it should be struck. How do others feel about this? I thought the discussion trend was going towards "do not deference atom:ids". >May I suggest this wording for the time being: > >" The "atom:id" element's content conveys a permanent, >globally unique identifier for the feed. It MUST NOT change over >time, even if the feed is relocated. An atom:head element MAY >contain an atom:id element, but MUST NOT contain more than one. The >content of this element, when present, MUST be a string of Unicode >characters encoded as UTF-8. When atom:id elements are compared, >they MUST be compared on a character-by-character basis. I don't think that would not work in a document whose encoding is anything other than UTF-8. > It is not a goal that atom:id be usable for retrieval of information. I'm OK with that wording. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 3 21:50:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00646 for ; Tue, 3 Aug 2004 21:50:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i741hNrC022868; Tue, 3 Aug 2004 18:43:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i741hNof022867; Tue, 3 Aug 2004 18:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i741hLW2022855 for ; Tue, 3 Aug 2004 18:43:22 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 24920 invoked by uid 65534); 4 Aug 2004 01:43:22 -0000 Received: from dsl-082-082-072-206.arcor-ip.net (EHLO localhost) (82.82.72.206) by mail.gmx.net (mp006) with SMTP; 04 Aug 2004 03:43:22 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Sam Ruby Cc: atom-syntax@imc.org Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) Date: Wed, 04 Aug 2004 03:43:11 +0200 Message-ID: <41393dd8.892450616@smtp.bjoern.hoehrmann.de> References: <14290954.1091493822057.JavaMail.dtcd@mac.com> <410EE6A7.30502@intertwingly.net> <13060801.1091548201912.JavaMail.dtcd@mac.com> <410FC2A4.5080301@intertwingly.net> In-Reply-To: <410FC2A4.5080301@intertwingly.net> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Sam Ruby wrote: >Spending a few minutes with .Net's Sytem.URI class, and in particular >it's constructor, .ToString() and .Equals() methods, indicate to me that >even non-spiders will tend to normalize; so the second approach seems >the most prudent. It seems quite odd to use an URI processor to process the content of atom:id elements unless you want to normalize the URI or process it in other ways (i.e., read meaning into something that is defined to have no meaning). Why would you do it? From owner-atom-syntax@mail.imc.org Tue Aug 3 22:18:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02541 for ; Tue, 3 Aug 2004 22:18:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i742Ba2M025130; Tue, 3 Aug 2004 19:11:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i742BaBp025129; Tue, 3 Aug 2004 19:11:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i742BaYB025116; Tue, 3 Aug 2004 19:11:36 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from c-24-30-98-23.we.client2.attbi.com ([24.30.98.23] helo=[192.168.0.20]) by web02.designerslab.net with esmtp (Exim 4.34) id 1BsBFj-0005Bv-Ta; Wed, 04 Aug 2004 02:11:40 +0000 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 03 Aug 2004 22:11:39 -0400 Subject: Re: A simpler proposal: PaceAtomIDAsString From: Robert Sayre To: Paul Hoffman / IMC , Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8/3/04 9:44 PM, "Paul Hoffman / IMC" wrote: > > >> If the comparison rules are to be character based over Unicode, >> that would suggest the Unicode encoding must also be specified so we >> know how many bytes are being used per character and so on. > > Nope, exactly wrong. It is character-by-character, not byte-by-byte. > How about putting it in an attribute, and directing implementors to compare normalized attribute values? [0] "When atom:id elements are compared, they MUST NOT be considered identical unless their @foo attributes have identical normalized values." Robert Sayre [0] http://www.w3.org/TR/REC-xml/#AVNormalize From owner-atom-syntax@mail.imc.org Tue Aug 3 22:40:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03902 for ; Tue, 3 Aug 2004 22:40:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i742YFQp026220; Tue, 3 Aug 2004 19:34:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i742YFes026219; Tue, 3 Aug 2004 19:34:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i742YD5E026199; Tue, 3 Aug 2004 19:34:13 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i742Vu53021102; Tue, 3 Aug 2004 20:31:56 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1W00KBWHT77K@edgemail1.Central.Sun.COM>; Tue, 03 Aug 2004 20:34:20 -0600 (MDT) Received: from [192.168.1.15] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1W00C5GHT6E4@mail.sun.net>; Tue, 03 Aug 2004 20:34:19 -0600 (MDT) Date: Tue, 03 Aug 2004 19:34:42 -0700 From: Tim Bray Subject: Re: A simpler proposal: PaceAtomIDAsString In-reply-to: To: Robert Sayre Cc: Atom Syntax , Paul Hoffman / IMC Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 3, 2004, at 7:11 PM, Robert Sayre wrote: > How about putting it in an attribute, and directing implementors to > compare > normalized attribute values? [0] Good idea in principle, but in practice I believe attribute normalization is kind of icky and tricky. James Clark complained about it to me at least once, and if James thinks it's hard, it's hard. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 3 22:49:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04708 for ; Tue, 3 Aug 2004 22:49:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i742hte9026800; Tue, 3 Aug 2004 19:43:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i742htOH026799; Tue, 3 Aug 2004 19:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i742hsnD026770 for ; Tue, 3 Aug 2004 19:43:54 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 20069 invoked by uid 65534); 4 Aug 2004 02:43:55 -0000 Received: from dsl-082-082-072-206.arcor-ip.net (EHLO localhost) (82.82.72.206) by mail.gmx.net (mp021) with SMTP; 04 Aug 2004 04:43:55 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Paul Hoffman / IMC Cc: atom-syntax@imc.org Subject: Re: A simpler proposal: PaceAtomIDAsString Date: Wed, 04 Aug 2004 04:43:44 +0200 Message-ID: <413a4850.895131410@smtp.bjoern.hoehrmann.de> References: <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Paul Hoffman / IMC wrote: >>Hmm, it would make more sense to me to specify that the content must >>be for example the uc(md5_hex()) of some reasonably unique data > >That's good if you want opaque identifiers, but I haven't heard any >need (or even desire!) for those so far. Well, as far as I can see, none of the arguments against specific URI schemes, specific kinds of URIs, specific forms of URIs, etc. applies to such identifiers... and I do not understand how that would be more opaque than what you propose. From owner-atom-syntax@mail.imc.org Wed Aug 4 00:32:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10189 for ; Wed, 4 Aug 2004 00:32:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i744OMTK034421; Tue, 3 Aug 2004 21:24:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i744OM40034420; Tue, 3 Aug 2004 21:24:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i744OLjS034410 for ; Tue, 3 Aug 2004 21:24:22 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 11366 invoked by uid 65534); 4 Aug 2004 04:24:23 -0000 Received: from dsl-082-082-072-206.arcor-ip.net (EHLO localhost) (82.82.72.206) by mail.gmx.net (mp003) with SMTP; 04 Aug 2004 06:24:23 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: atom-syntax@imc.org Subject: type attribute content model Date: Wed, 04 Aug 2004 06:24:11 +0200 Message-ID: <413b6217.901729508@smtp.bjoern.hoehrmann.de> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, Section 3.1.1, '"type" Attribute' states: [...] Content constructs MAY have a "type" attribute, whose value indicates the media type of the content. When present, this attribute's value MUST be a media type [RFC2045]. If this attribute is not present, processors MUST behave as if it were present with a value of "text/ plain". [...] and section 3.4.2, '"type" Attribute' states: [...] Link constructs MUST have a type attribute, whose value MUST be a media type [RFC2045]. [...] This reference to RFC 2045 for the definition of "media type" is rather vague as RFC 2045 uses the term to refer to top-level types such as "text" and "application", to combinations of top-level types and sub-types such as "text/css" and "application/rdf+xml" and to the value of the Content-Type header which could for example be something like "application/xhtml+xml;profile='http://example.org/basic10.dtd'". A number of questions arise from this fact, see e.g. http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de What is the intent here? From owner-atom-syntax@mail.imc.org Wed Aug 4 00:40:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10631 for ; Wed, 4 Aug 2004 00:40:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i744XP2O035072; Tue, 3 Aug 2004 21:33:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i744XPpg035071; Tue, 3 Aug 2004 21:33:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i744XOQ4035062 for ; Tue, 3 Aug 2004 21:33:24 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040804043326.29140.qmail@web41213.mail.yahoo.com> Received: from [67.160.86.162] by web41213.mail.yahoo.com via HTTP; Tue, 03 Aug 2004 21:33:26 PDT Date: Tue, 3 Aug 2004 21:33:26 -0700 (PDT) From: Dare Obasanjo Subject: Re: A simpler proposal: PaceAtomIDAsString To: Paul Hoffman / IMC , Atom WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Paul Hoffman / IMC wrote: > At 3:14 PM -0700 8/3/04, Dare Obasanjo wrote: > >Where are the guidelines that make it so that > people > >can create globally unique identifiers using > arbitrary > >strings? > > Um, in the same place as the guidelines that make it > so that people > can create globally unique identifiers using URIs? > > That is, they are the same. I still don't get it. For URI schemes the consensus seemed to be to pick some combination of (scheme + domain + date + extra gunk) for individual schemes to maintain uniqueness. Are you claiming that using some similar syntax will be adopted for saying that any arbitrary string can be an atom:id, if so where in the Pace is this highlighted? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 4 04:53:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19307 for ; Wed, 4 Aug 2004 04:53:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i748dD6B022783; Wed, 4 Aug 2004 01:39:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i748dDBP022782; Wed, 4 Aug 2004 01:39:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.afp.com (smtp2.afp.com [158.50.208.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i748dCvh022736 for ; Wed, 4 Aug 2004 01:39:12 -0700 (PDT) (envelope-from laurent.lemeur@afp.com) Received: from alox.afp.com (unknown [158.50.165.141]) by smtp2.afp.com (Sendmail) with ESMTP id D13994617F for ; Wed, 4 Aug 2004 10:39:04 +0200 (CEST) Received: from sdtc05 (sdtc05.afp.local [158.50.180.103]) by alox.afp.com (8.12.9/8.12.9) with ESMTP id i748cut6002031 for ; Wed, 4 Aug 2004 10:38:56 +0200 (METDST) From: "Laurent Le Meur" To: "'Atom-Syntax'" Subject: RE : RE : Identity conundrum ... and links Date: Wed, 4 Aug 2004 10:38:57 +0200 Message-ID: <001601c479fe$7b7c8a30$67b4329e@afp.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: X-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i748dCvh022775 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > What I am sure of, is that the versioning and more professional > publishing > model should be reflected with an extension. How this extension may look > like is still very blue-ish, but I think Ken's very old proposal of just > having a element in the , that exists in a known > namespace, would be a good solution. [llm] It is only a personal opinion, but I believe that an Atom professional extension not supported by the news industry will be a loss of time. This is why synchronization between Atom and NewsML 2 would still be worth studying (that was briefly discussed during the News Standards Summit in Philadelphia last winter http://www.idealliance.org/news-summit/, and an article written by F.Zimmerman some time ago discusses this view at http://www.wfzimmerman.com/article.php/20040504183303433). > > Yes. That's why an extension mechanism that alters the semantics of > atom:id also can alter the requirements for atom:id. Such an extension > (or rather; profile) could state that created in a URI scheme that supports versioning>, or even > . > [llm] I'm concerned by the idea of having varying semantics for a given element: a conceptual model should be stable. But I would perfectly understand profiles applied to the processing model (at a given level the processor must do this and that, and maybe yes, a given element value must fulfill this and that requirement). Amts llm From owner-atom-syntax@mail.imc.org Wed Aug 4 08:05:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29401 for ; Wed, 4 Aug 2004 08:05:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74BpaiP071606; Wed, 4 Aug 2004 04:51:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74Bpaqb071605; Wed, 4 Aug 2004 04:51:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74BpZWD071591 for ; Wed, 4 Aug 2004 04:51:35 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 43304 invoked from network); 4 Aug 2004 11:51:21 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 4 Aug 2004 11:51:21 -0000 Received: from 194.203.191.188 ([194.203.191.188]) by webmail.djpowell.net (IMP) with HTTP for ; Wed, 4 Aug 2004 12:51:21 +0100 Message-ID: <1091620281.4110cdb9938a3@webmail.djpowell.net> Date: Wed, 4 Aug 2004 12:51:21 +0100 From: David Powell To: Paul Hoffman / IMC Cc: Atom WG Subject: Re: A simpler proposal: PaceAtomIDAsString References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 194.203.191.188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Paul Hoffman / IMC : > Greetings again. The earlier thread on atom:id made it clear that > people really, really want to compare things consistently, and that > using URIs might get in the way of that. Thus, I have made a > simplifying proposal at > . > > It explicitly allows URIs for people who want URIs, and allows plain > text for the rest of us. -1 The main advantage in using URIs is that it provides a hierarchy of namespaces which can be delegated out from authorities to publishers to ensure uniqueness of ids. ISBN numbers, XML Namespaces, RFC822 Message-Ids, even UUIDs use namespaces in this way to help ensure global uniqueness of ids. I don't see how allowing people to create ids in any format that they feel like, without requiring any namespacing, can improve on the situation of having namespacing, albeit namespacing that might fail in edge cases. My prefered aproach would be for atom:ids to be created as URIs to aid uniqueness, but to then to be stored, and compared as opaque strings by all parties after that point. I don't see why any normalization or canonicalization should be required within Atom because Atom does not require dereferencing of ids. I don't see how Tim's argument that spiders normalize URLs applies to atom:ids. Atom ids provide no guarantee of dereferenceability, and they will not be written on busses. Spiders normalize URLs because URLs get copied around by humans, and if two different locators work for the same site, then they are equivalent. This is not the case for Atom ids. Atom ids are not used as locators within Atom, they get created once by the publisher, and then stored in a database or wherever, if they are different then they are different. I would agree that Atom agents should be allowed to normalize FeedURIs in Atom then I would agree because the FeedURI is used as a locator, variants will work, so it makes sense that these variants should be treated as equivalent. This does not apply to atom:ids. If publishers wan't to make their id's dereferenceable then they can do, and agents such as spiders that dereference those ids can consider canonicalizing them, but that is nothing to do with Atom. -- Dave From owner-atom-syntax@mail.imc.org Wed Aug 4 08:38:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01604 for ; Wed, 4 Aug 2004 08:38:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74CVQsf074594; Wed, 4 Aug 2004 05:31:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74CVQlX074593; Wed, 4 Aug 2004 05:31:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74CVOig074577 for ; Wed, 4 Aug 2004 05:31:25 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i74CWhUM030983; Wed, 4 Aug 2004 08:32:43 -0400 Message-ID: <4110D71B.3020807@intertwingly.net> Date: Wed, 04 Aug 2004 08:31:23 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: Atom WG Subject: Re: A simpler proposal: PaceAtomIDAsString References: <1091620281.4110cdb9938a3@webmail.djpowell.net> In-Reply-To: <1091620281.4110cdb9938a3@webmail.djpowell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > > I don't see how allowing people to create ids in any format that they feel > like, > without requiring any namespacing, can improve on the situation of > having namespacing, albeit namespacing that might fail in edge cases. > > My prefered aproach would be for atom:ids to be created as URIs to aid > uniqueness, but to then to be stored, and compared as opaque strings by all > parties after that point. I don't see why any normalization or canonicalization > should be required within Atom because Atom does not require dereferencing of > ids. If we state that atom:id is a URI, then this likely will be captured in a schema as xsd:anyURI. On platforms like .Net, this will generate code that uses the native System.Uri class. This will convey some advantages in producing feeds and protocol requests in that there are built-in checks to ensure that the URIs produces are all well-formed. On the consumption side, however, this will imply that all URIs are effectively canonicalized. IMHO, we should recognize that fact and either require canonicalization (my preference), or drop the requirement that ids be URIs and live with the consequences of having to deal with feeds like the following (look for guid): http://www.keepmedia.com/rss/featurednews/ http://www.microsite.reuters.com/rss/topNews - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 4 12:03:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13919 for ; Wed, 4 Aug 2004 12:03:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74FsRYV090637; Wed, 4 Aug 2004 08:54:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74FsRve090636; Wed, 4 Aug 2004 08:54:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74FsQar090618 for ; Wed, 4 Aug 2004 08:54:26 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i74FsN53032442 for ; Wed, 4 Aug 2004 10:54:23 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i74FsNtS032438; Wed, 4 Aug 2004 10:54:23 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom WG Subject: Re: A simpler proposal: PaceAtomIDAsString References: From: Ken MacLeod Date: 04 Aug 2004 10:54:22 -0500 In-Reply-To: Message-ID: Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman / IMC writes: > Greetings again. The earlier thread on atom:id made it clear that > people really, really want to compare things consistently, and that > using URIs might get in the way of that. Thus, I have made a > simplifying proposal at > . > > It explicitly allows URIs for people who want URIs, and allows plain > text for the rest of us. -1 to an "internal (to Atom systems) only" identifier. As defined, this identifier can only be considered an "internal" identifier, not a public identifier. The suggestion that a "public identifier can be used in this field to create a unique internal identifier" does not make atom:id a public identifier and means that systems that interface with Atom have no defined way of using it as public identifier. There is a significant difference between saying that "atom:id is not intended as a primary access mechanism" and "atom:id is not intended to be dereferencable". Currently, most of the proposals say the latter, when I believe what is meant is the former. "Dereferencing" is a broader term than whether a resource can be fetched using HTTP or FTP. It also means the ability to use the URI in finding other locations of the resource and in making references to the resource[1]. An "internal only" identifier restricts that to Atom enabled processing systems only, which seems short sighted. Previous proposals have used the term "URI" with the implication that they are "public identifiers", mostly because URIs are the only significant public identification system in use on the Internet today. If the intent is to not use public identifiers for Atom resources, that should be stated more clearly so implementors can be more informed about what they are seeking concensus on. -- Ken From owner-atom-syntax@mail.imc.org Wed Aug 4 12:24:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15189 for ; Wed, 4 Aug 2004 12:24:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GIbCi092657; Wed, 4 Aug 2004 09:18:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GIbKe092656; Wed, 4 Aug 2004 09:18:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GIXbR092643 for ; Wed, 4 Aug 2004 09:18:35 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i74GIU53032720 for ; Wed, 4 Aug 2004 11:18:31 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i74GIUSI032716; Wed, 4 Aug 2004 11:18:30 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: From: Ken MacLeod Date: 04 Aug 2004 11:18:30 -0500 In-Reply-To: Message-ID: Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tim Bray writes: > I just went back and revisited a *lot* of email and Wiki text on the > subject of atom:id, and I think that a fairly clear rough consensus > emerges from that. I've published what I think it is at > http://intertwingly.net/wiki/pie/PaceBasicAtomID > > Bearing in mind the amount of work we've already put into this, and > the fact that debate on this subject is apt to create permathreads, > please seriously consider, if you think you could live with this > language, resisting the urge to launch a debate about one phrase or > another. Still +1 on this one. I note the wording about it being a URI has been added. Given the recent misunderstanding about dereferencing, I suggest the following: "It is not a goal that atom:id be usable for retrieval of information." be changed to: "atom:id is a public identifier that can be used to reference the Atom resource on the public Internet, but it is not a goal that the atom:id be directly accessible using this URI." Then following, "Given that HTTP URIs can be used for retrieval" be changed to: "Given that HTTP URIs can be used directly for retrieval" and, "which does not imply information-retrieval semantics" to: "which does not imply direct access semantics" -- Ken From owner-atom-syntax@mail.imc.org Wed Aug 4 12:27:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15637 for ; Wed, 4 Aug 2004 12:27:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKQJu092847; Wed, 4 Aug 2004 09:20:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GKQkF092846; Wed, 4 Aug 2004 09:20:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-129-167.ietf60.ietf.org [130.129.129.167]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKKaV092821; Wed, 4 Aug 2004 09:20:23 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1091620281.4110cdb9938a3@webmail.djpowell.net> References: <1091620281.4110cdb9938a3@webmail.djpowell.net> Date: Wed, 4 Aug 2004 09:20:31 -0700 To: David Powell From: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Cc: Atom WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:51 PM +0100 8/4/04, David Powell wrote: >-1 > >The main advantage in using URIs is that it provides a hierarchy of namespaces >which can be delegated out from authorities to publishers to ensure uniqueness >of ids. Fully disagree. Those namespaces can be expressed as strings as easily (or more easily) than as URIs. >ISBN numbers, XML Namespaces, RFC822 Message-Ids, even UUIDs use namespaces in >this way to help ensure global uniqueness of ids. For example, ISBN numbers and RFC2822 Message-Ids are created as strings, not as URIs. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 4 12:27:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15658 for ; Wed, 4 Aug 2004 12:27:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKNLb092836; Wed, 4 Aug 2004 09:20:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GKNmC092835; Wed, 4 Aug 2004 09:20:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-129-167.ietf60.ietf.org [130.129.129.167]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKKaR092821 for ; Wed, 4 Aug 2004 09:20:22 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <413a4850.895131410@smtp.bjoern.hoehrmann.de> References: <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <413a4850.895131410@smtp.bjoern.hoehrmann.de> Date: Wed, 4 Aug 2004 09:12:51 -0700 To: atom-syntax@imc.org From: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:43 AM +0200 8/4/04, Bjoern Hoehrmann wrote: >* Paul Hoffman / IMC wrote: >>>Hmm, it would make more sense to me to specify that the content must >>>be for example the uc(md5_hex()) of some reasonably unique data >> >>That's good if you want opaque identifiers, but I haven't heard any >>need (or even desire!) for those so far. > >Well, as far as I can see, none of the arguments against specific URI >schemes, specific kinds of URIs, specific forms of URIs, etc. applies >to such identifiers... and I do not understand how that would be more >opaque than what you propose. Sorry, I'm confused. I am not proposing making IDs opaque; I thought you were. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 4 12:28:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15813 for ; Wed, 4 Aug 2004 12:28:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKQvw092854; Wed, 4 Aug 2004 09:20:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GKQ2i092853; Wed, 4 Aug 2004 09:20:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-129-167.ietf60.ietf.org [130.129.129.167]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKKaT092821; Wed, 4 Aug 2004 09:20:22 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20040804043326.29140.qmail@web41213.mail.yahoo.com> References: <20040804043326.29140.qmail@web41213.mail.yahoo.com> Date: Wed, 4 Aug 2004 09:17:36 -0700 To: Dare Obasanjo , Atom WG From: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:33 PM -0700 8/3/04, Dare Obasanjo wrote: >I still don't get it. For URI schemes the consensus >seemed to be to pick some combination of (scheme + >domain + date + extra gunk) for individual schemes to >maintain uniqueness. Agree. > Are you claiming that using some >similar syntax will be adopted for saying that any >arbitrary string can be an atom:id, if so where in the >Pace is this highlighted? No, I copied the text from the current pace. Whether or not people like the "strings instead of URIs" idea, we can add the proposed suggestion of "domain + date + extra gunk". Suggesting that the "extra gunk" have randomness in it might be useful as well. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 4 12:28:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15883 for ; Wed, 4 Aug 2004 12:28:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKMhI092828; Wed, 4 Aug 2004 09:20:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GKMpu092827; Wed, 4 Aug 2004 09:20:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-129-167.ietf60.ietf.org [130.129.129.167]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GKKaP092821 for ; Wed, 4 Aug 2004 09:20:21 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Wed, 4 Aug 2004 09:10:16 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:11 PM -0400 8/3/04, Robert Sayre wrote: >How about putting it in an attribute, and directing implementors to compare >normalized attribute values? [0] That's OK with me, if we believe that everyone's normalization code works. At 7:34 PM -0700 8/3/04, Tim Bray wrote: >Good idea in principle, but in practice I believe attribute >normalization is kind of icky and tricky. James Clark complained >about it to me at least once, and if James thinks it's hard, it's >hard. Sounds like a reasonable reason not to do it, but others have gotten normalization down reasonably well in the real world so far. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 4 12:39:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17009 for ; Wed, 4 Aug 2004 12:39:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GUBq9093702; Wed, 4 Aug 2004 09:30:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74GUBB0093701; Wed, 4 Aug 2004 09:30:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74GUAsM093692 for ; Wed, 4 Aug 2004 09:30:10 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i74GRn53019366 for ; Wed, 4 Aug 2004 10:27:49 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1X00JJTKICTD@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 04 Aug 2004 10:30:12 -0600 (MDT) Received: from [192.168.1.15] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1X00CEHKIBE1@mail.sun.net> for atom-syntax@imc.org; Wed, 04 Aug 2004 10:30:12 -0600 (MDT) Date: Wed, 04 Aug 2004 09:30:35 -0700 From: Tim Bray Subject: Re: A simpler proposal: PaceAtomIDAsString In-reply-to: <4110D71B.3020807@intertwingly.net> To: Sam Ruby Cc: Atom WG , David Powell Message-id: <9C803B26-E633-11D8-A4DC-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1091620281.4110cdb9938a3@webmail.djpowell.net> <4110D71B.3020807@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On the whole atom:id thing, may I suggest that this is mostly about marketing, not technology. First of all, I acknowledge that I was originally against the idea of atom:id but have become convinced that it's sound, in part because of the immense numbers of duplicate entries in my RSS feeds (particularly the synthetic ones) every morning. I think the most important thing about atom:id is that we market the hell out of it, make it clear that it's required to be there and required to be unique and required not to change. So it's an evangelism/marketing problem, not a technical problem. Second, personally I can live with pretty well any of the proposals out there, the one I advanced saying they're URIs but dereferencing is a non-goal and with a lot of drum-banging about persistance and uniqueness, or Sam's proposal adding the requirement that have to be canonicalized (same drum-banging) or Paul's suggestion that they just be strings (same drum-banging). So for me, the tactics are: grab whatever will build consensus and make sure we get the evangelism right. The only thing I'm clearly against is specifying a URI scheme. So the meaningful arguments on URI vs string seem pretty simple: On the upside, IF we say it's a URI, then there exist helpful and widely-implemented ways around to mint URIs that have an excellent chance of being globally unique and persistent, and it will cut down on the required creativity and maybe increase the net chances of getting useful atom:id's. On the downside, if we say it's a URI, some people are moronically going to assume it has to be the current URI in use, and change it when they move the entry, thus defeating the purpose. Of those two, the upside of URIs looks maybe a little better than the downside, but if a majority disagrees, hey, I'm there. But either way, let's get lots of shouting and yelling in the spec about the importance of uniqueness and persistence. If others agree that the technical arguments aren't that big a deal, maybe I should run another survey and we all agree to get behind whatever gets the plurality? BTW, I totally don't think the arguments from URI comparison are relevant, the most insanely overaggressive URI comparator in the world isn't going to be producing false positives unless someone actively sets out to be malicious, so I don't think this is a factor in choosing whether to not to make atom:id a URI. -Tim From owner-atom-syntax@mail.imc.org Wed Aug 4 13:12:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19693 for ; Wed, 4 Aug 2004 13:12:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74H4gPM096333; Wed, 4 Aug 2004 10:04:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74H4gO4096332; Wed, 4 Aug 2004 10:04:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74H4fTi096325 for ; Wed, 4 Aug 2004 10:04:41 -0700 (PDT) (envelope-from eliast@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so329010rnl for ; Wed, 04 Aug 2004 10:04:41 -0700 (PDT) Received: by 10.38.171.1 with SMTP id t1mr74964rne; Wed, 04 Aug 2004 10:04:41 -0700 (PDT) Message-ID: <905f7c9104080410048e01e1b@mail.gmail.com> Date: Wed, 4 Aug 2004 13:04:41 -0400 From: Elias Torres Reply-To: elias@torrez.us To: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Cc: Dare Obasanjo , Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040804043326.29140.qmail@web41213.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit BTW, all that would be doing is re-creating what URNs are supposed to be doing in the first place and what other URN specs have already defined beyond what we are responsible for doing in this spec. This discussion is getting nowhere. This issue it's just a matter of compromise, we do not need to invent something new. Again in summary we have: 1. Use URIs 2. Use one or more existing URN schemes 3. Use xsd:strings From monitoring the list for a few weeks now, I think there are plenty of people that have problems with URIs (except for Tim, Martin and a couple of others) for the overall reason that they are too broad and general to make them "identifiers", plus other issues like normalization, encoding and parsing. IDAsString is trying to solve some of the issues from URIs (byte-per-byte, char-per-char, codepoint-per-codepoint, whatever), but starts all over on the fact that it does not help the users/applications to generate a proper identification. Lastly, the problem with picking an existing URN scheme is that it's too specific and it might not satisfy everyone. For the last argument, I disagree. The spec is responsible to limit elements if we feel that it will help those using them. Why use XML? Why require only one title? Why have author? Why is author string? Why is author binary? For the answer to the questions, I feel it's ok to pick something and stick with it. What is the purpose of atom:id? To identify. They need to be what we say they will and so people will be able to write code that makes use of them. atom:id is extremely important for this type of technology and so we have a chance of really making a difference. Punting by using URIs will not be of great use, even though it will sound flexible, extensible and/or general. Tim/Paul as chairs need to help us solve this discussion because it's taking too long. I have tried to compromise by not making anymore waves, but the issue keeps coming back over and over. I know where Tim stands, but I think that enough people have issues with URIs so we need to start narrowing the choices down, vote/whatever and move on. I know URIs will never be such a bad end-result because we usually prefer to make decisions that result in less value rather than cause more harm. URIs will cause less harm than if we pick the wrong scheme or strings, but since many are raising concerns, we need someone to arbitrate not take a side. From the RFC: A URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier. That identifier is drawn from one of a set of defined namespaces, each of which has its own set name structure and assignment procedures. Elias Torres On Wed, 4 Aug 2004 09:17:36 -0700, Paul Hoffman / IMC wrote: > > At 9:33 PM -0700 8/3/04, Dare Obasanjo wrote: > >I still don't get it. For URI schemes the consensus > >seemed to be to pick some combination of (scheme + > >domain + date + extra gunk) for individual schemes to > >maintain uniqueness. > > Agree. > > > Are you claiming that using some > >similar syntax will be adopted for saying that any > >arbitrary string can be an atom:id, if so where in the > >Pace is this highlighted? > > No, I copied the text from the current pace. Whether or not people > like the "strings instead of URIs" idea, we can add the proposed > suggestion of "domain + date + extra gunk". Suggesting that the > "extra gunk" have randomness in it might be useful as well. > > > > --Paul Hoffman, Director > --Internet Mail Consortium > > From owner-atom-syntax@mail.imc.org Wed Aug 4 14:25:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26092 for ; Wed, 4 Aug 2004 14:25:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74IFwJm003223; Wed, 4 Aug 2004 11:15:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74IFwNT003222; Wed, 4 Aug 2004 11:15:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74IFvuv003209 for ; Wed, 4 Aug 2004 11:15:58 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i74IHMbO014867; Wed, 4 Aug 2004 14:17:22 -0400 Message-ID: <411127E0.8010503@intertwingly.net> Date: Wed, 04 Aug 2004 14:16:00 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom-Syntax Syntax Subject: Re: A simpler proposal: PaceAtomIDAsString References: <1091620281.4110cdb9938a3@webmail.djpowell.net> <4110D71B.3020807@intertwingly.net> <9C803B26-E633-11D8-A4DC-000A95A51C9E@sun.com> In-Reply-To: <9C803B26-E633-11D8-A4DC-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > If others agree that the technical arguments aren't that big a deal, > maybe I should run another survey and we all agree to get behind > whatever gets the plurality? It probably is time for a poll, but my fear is that the way the question is phrased will determine the outcome. I care more about "clearly and thoroughly specified" than I do about uri vs string. Let me enumerate the scenario that concerns me: 1) a SOURCE generates a feed containing entries with ids which are not in canonical form. Just to make the scenario definate, let's say that the atom:ids feeds contain a "%7E" in the path portion of the URI. 2) a REPUBLISHER (like PlanetSun, but written in .Net) consumes the feeds based on the published schema and serializes an aggregated site based on the same. The ids are morphed from a "%7E" to a "~" in the process. 3) a CONSUMER written in Java will see these URIs as being different. (Note: a CONSUMER written in .Net won't see any problems). So: if we go with URIs, I want to make sure that we need to select one of three "culprits" in the above scenario: 1) The SOURCE generated a feed that is invalid 2) The REPUBLISHER made an invalid transformation 3) The CONSUMER didn't implement equivalence properly If we decide that the SOURCE is wrong, then this is something that can easily be checked for in the feedvalidator and will generally not involve much of a burden to producers. If we decide that the REPUBLISHER is wrong in the scenario above, then the schema should be xsd:string and we shouldn't be messing with URIs at all (IMHO). We lose some benefits of URIs, but interoperability doesn't suffer. If we decide that the CONSUMER is wrong, then the overhead is a bit more; while SOURCES have the luxury of knowing their own URI scheme, CONSUMERS have to deal with every eventuality. My concern is that if we don't pick one, the inevitable result will be that the burden is passed down to the CONSUMER and that it will become common knowledge that consumers will need to aggresively normalize URIs. Such knowledge won't be backed up by any spec text. So... if there are choices, I want to make sure that they all are cleanly and thoroughly specified. I personally will vote against any choices which involve hand waving in the form of "the problems aren't likely to occur all that often anyway". - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 4 14:28:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26315 for ; Wed, 4 Aug 2004 14:28:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74IJKIT003581; Wed, 4 Aug 2004 11:19:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74IJKeq003580; Wed, 4 Aug 2004 11:19:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i74IJIDD003573 for ; Wed, 4 Aug 2004 11:19:19 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 21152 invoked from network); 4 Aug 2004 18:21:59 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 4 Aug 2004 18:21:59 -0000 Subject: Re: A simpler proposal: PaceAtomIDAsString From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Atom syntax In-Reply-To: <9C803B26-E633-11D8-A4DC-000A95A51C9E@sun.com> References: <1091620281.4110cdb9938a3@webmail.djpowell.net> <4110D71B.3020807@intertwingly.net> <9C803B26-E633-11D8-A4DC-000A95A51C9E@sun.com> Content-Type: text/plain Message-Id: <1091643580.2020.52.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 04 Aug 2004 19:19:40 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-04 at 17:30, Tim Bray wrote: > First of all, I acknowledge that I was originally against the idea of > atom:id but have become convinced that it's sound, in part because of > the immense numbers of duplicate entries in my RSS feeds (particularly > the synthetic ones) every morning. > > I think the most important thing about atom:id is that we market the > hell out of it, make it clear that it's required to be there and > required to be unique and required not to change. So it's an > evangelism/marketing problem, not a technical problem. A good perspective Tim. Without the marketing hype I simply can't see it happening, there is no carrot, and no stick. It'll confuse readers is of very little concern to the non-egotistical author. On the evil side, if I choose a really well read blog, and duplicate their url's as id's, can I 'hack' my way into being well read? If these id values may not be de-referenced, perhaps yes? Will this be the equivalent of moving up the google ratings? Is this a possibility? Can we protect against that somehow? -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Wed Aug 4 14:52:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28270 for ; Wed, 4 Aug 2004 14:52:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74IijlA005349; Wed, 4 Aug 2004 11:44:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74IijRl005348; Wed, 4 Aug 2004 11:44:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74IijHe005342 for ; Wed, 4 Aug 2004 11:44:45 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i74Iin2G010014; Wed, 4 Aug 2004 11:44:49 -0700 (PDT) Received: from [12.40.110.213] (wireless-12-40-110-213.bryantpark.org [12.40.110.213] (may be forged)) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i74IiJBA007033; Wed, 4 Aug 2004 11:44:21 -0700 (PDT) In-Reply-To: <411127E0.8010503@intertwingly.net> References: <1091620281.4110cdb9938a3@webmail.djpowell.net> <4110D71B.3020807@intertwingly.net> <9C803B26-E633-11D8-A4DC-000A95A51C9E@sun.com> <411127E0.8010503@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-20--478763335; protocol="application/pkcs7-signature" Message-Id: <51A8DEFD-E646-11D8-B75F-000A95DC3D90@mac.com> Cc: Atom-Syntax Syntax From: Graham Subject: Re: A simpler proposal: PaceAtomIDAsString Date: Wed, 4 Aug 2004 14:44:29 -0400 To: Sam Ruby X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-20--478763335 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 4 Aug 2004, at 2:16 pm, Sam Ruby wrote: > 2) a REPUBLISHER (like PlanetSun, but written in .Net) consumes the > feeds based on the published schema and serializes an aggregated site > based on the same. The ids are morphed from a "%7E" to a "~" in the > process. The republisher is wrong for mangling the id. http://www.example.com/~user/ and http://www.example.com/%7Euser/ are clearly not the same. But there's no need for PaceAtomIDAsString (which is an unworkable idea) - just state in the verbiage about it being good to use the same id when republishing that it has to be the same characters. I know this isn't schema-friendly, but we've said before that schemas are a secondary concern. Graham --Apple-Mail-20--478763335 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODA0MTg0NDMwWjAjBgkqhkiG9w0BCQQxFgQUPsdPuT/Z8H3bHgaJPCXC0Hr2 YucweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAtZYNgMpooiYzClVIPMgT1Vt0 VYpz4L9pF8Htkg10Gaa4ODoT8G7w6EdVnoYJKQ3QHaWhSTi7xrrJLMju2uluq+5y0hrrvWoDBIOf N6aqNNTfbN+gQDkCIJE9d3WgAcGFUwWHeSEFwoXR2N0fCJxjy/n32AXsh0Vjq04R/xiio9mEmEY+ 8y3PGWV6YwQi6SFd+jDL+hQ15SZcivReKT8s7zwCqfB9bINH8nlIQVO7CbAaHktjVnboNJLePwGo dA/taZDQOtizOMdVlV26sC/bLZCKHGzm0ZPJPc4HNx/TGp7Vz6+rbL8hQ5HqoE5f0POLEfsecoph SrTfVOMQs1SkswAAAAAAAA== --Apple-Mail-20--478763335-- From owner-atom-syntax@mail.imc.org Wed Aug 4 15:17:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01286 for ; Wed, 4 Aug 2004 15:17:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74J9aJU007253; Wed, 4 Aug 2004 12:09:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74J9aAQ007252; Wed, 4 Aug 2004 12:09:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41204.mail.yahoo.com (web41204.mail.yahoo.com [66.218.93.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i74J9aZI007238 for ; Wed, 4 Aug 2004 12:09:36 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040804190933.44723.qmail@web41204.mail.yahoo.com> Received: from [207.46.228.16] by web41204.mail.yahoo.com via HTTP; Wed, 04 Aug 2004 12:09:33 PDT Date: Wed, 4 Aug 2004 12:09:33 -0700 (PDT) From: Dare Obasanjo Subject: Re: A simpler proposal: PaceAtomIDAsString To: davep@dpawson.co.uk, Atom syntax In-Reply-To: <1091643580.2020.52.camel@homer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Dave Pawson wrote: > > On the evil side, if I choose a really well read > blog, and duplicate > their url's as id's, can I 'hack' my way into being > well read? If these > id values may not be de-referenced, perhaps yes? > Will this be the > equivalent of moving up the google ratings? > Is this a possibility? > Can we protect against that somehow? I dunno. What happens if you create an RSS feed and use the links to a popular weblog as values as your rdf:about/guid values? Whatever happens there is exactly what would happen in the Atom case. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 4 15:58:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04366 for ; Wed, 4 Aug 2004 15:58:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JlMw0010465; Wed, 4 Aug 2004 12:47:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74JlMoc010464; Wed, 4 Aug 2004 12:47:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JlMLY010457 for ; Wed, 4 Aug 2004 12:47:22 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i74JlMhA001268; Wed, 4 Aug 2004 15:47:22 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BLM62500 (AUTH bob@wyman.us); Wed, 4 Aug 2004 15:47:21 -0400 (EDT) Message-Id: <200408041947.BLM62500@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Sam Ruby'" Cc: "'Atom WG'" , "'David Powell'" Subject: RE: A simpler proposal: PaceAtomIDAsString Date: Wed, 4 Aug 2004 15:47:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <9C803B26-E633-11D8-A4DC-000A95A51C9E@sun.com> Thread-Index: AcR6Q0wEyjS6wD0FT9Ct79Kcr+CQ1gAF+IVg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > The only thing I'm clearly against is > specifying a URI scheme. ... > let's get lots of shouting and yelling in the spec > about the importance of uniqueness and persistence. It seems to me that one way to increase the level of understanding of how to do things properly would be to provide one of the following: 1. An example URI scheme (i.e. show a tag or newsml id and discuss why it meets the requirements of atom. 2. A recommended URI scheme or schemes (i.e. recommend one or more of tag, newsml, publicid, etc.) Would the level of objection to mentioning a specific scheme be reduced if we only presented the specific scheme or schemes as examples or recommendations? Personally, I think it is vital that readers of the spec be exposed to at least one "satisfactory" scheme before they go off to invent their own schemes. bob wyman From owner-atom-syntax@mail.imc.org Wed Aug 4 16:08:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04893 for ; Wed, 4 Aug 2004 16:08:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74K0UWg011832; Wed, 4 Aug 2004 13:00:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74K0UA4011831; Wed, 4 Aug 2004 13:00:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74K0TRr011825 for ; Wed, 4 Aug 2004 13:00:29 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i74JwA53006602 for ; Wed, 4 Aug 2004 13:58:10 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1X00MSCU8W5Q@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 04 Aug 2004 14:00:33 -0600 (MDT) Received: from [192.168.1.7] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1X00KOHU8V3N@mail.sun.net> for atom-syntax@imc.org; Wed, 04 Aug 2004 14:00:32 -0600 (MDT) Date: Wed, 04 Aug 2004 13:00:55 -0700 From: Tim Bray Subject: Re: A simpler proposal: PaceAtomIDAsString In-reply-to: <200408041947.BLM62500@ms8.netsolmail.com> To: bob@wyman.us Cc: "'Sam Ruby'" , "'Atom WG'" , "'David Powell'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200408041947.BLM62500@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 4, 2004, at 12:47 PM, Bob Wyman wrote: > 1. An example URI scheme (i.e. show a tag or newsml id and discuss > why it meets the requirements of atom. Well, tag: isn't registered and urn:newsml: is specifically limited to NewsML information, not Atom information. So one problem is that there actually isn't right now a terrifically attractive properly-registered scheme. Except of course for well-constructed and managed HTTP URIs, which is exactly what everyone is trying to avoid. -Tim From owner-atom-syntax@mail.imc.org Wed Aug 4 16:15:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05206 for ; Wed, 4 Aug 2004 16:15:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74KAX6x012425; Wed, 4 Aug 2004 13:10:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74KAX7d012424; Wed, 4 Aug 2004 13:10:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74KAXar012417 for ; Wed, 4 Aug 2004 13:10:33 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [18.29.0.30]) by homer.w3.org (Postfix) with ESMTP id C8E4E4F246; Wed, 4 Aug 2004 16:10:35 -0400 (EDT) Message-Id: <4.2.0.58.J.20040805050552.059245b8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 05 Aug 2004 05:08:50 +0900 To: Ken MacLeod , Atom Syntax From: Martin Duerst Subject: Re: PaceBasicAtomID - maybe we're done In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:18 04/08/04 -0500, Ken MacLeod wrote: >Still +1 on this one. I note the wording about it being a URI has >been added. > >Given the recent misunderstanding about dereferencing, I suggest the >following: > > "It is not a goal that atom:id be usable for retrieval of > information." > >be changed to: > > "atom:id is a public identifier that can be used to reference the > Atom resource on the public Internet, but it is not a goal that > the atom:id be directly accessible using this URI." I would be very careful with the term 'public identifier'. Regards, Martin. From owner-atom-syntax@mail.imc.org Wed Aug 4 16:19:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05444 for ; Wed, 4 Aug 2004 16:19:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74K8aK8012307; Wed, 4 Aug 2004 13:08:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74K8acQ012304; Wed, 4 Aug 2004 13:08:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74K8Z9S012289; Wed, 4 Aug 2004 13:08:35 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from c-24-30-98-23.we.client2.attbi.com ([24.30.98.23] helo=[127.0.0.1]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BsS3u-0004pm-Eb; Wed, 04 Aug 2004 20:08:34 +0000 Message-ID: <41111803.9070705@franklinmint.fm> Date: Wed, 04 Aug 2004 13:08:19 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: Re: A simpler proposal: PaceAtomIDAsString References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > At 10:11 PM -0400 8/3/04, Robert Sayre wrote: > >> How about putting it in an attribute, and directing implementors to >> compare >> normalized attribute values? [0] > > > That's OK with me, if we believe that everyone's normalization code > works. I tried the following in Mozilla and IE, both of which use non-validating parsers when you just view an xml file, I believe. I've grouped the elements where their normalized attribute values are expected to be identical. IE/MSXML appeared to trim the trailing whitespace in the third set of elements, which I don't believe it should do for CDATA attributes, but it was consistent. I don't see how we can compare based on anything else. Robert Sayre ]> From owner-atom-syntax@mail.imc.org Wed Aug 4 16:20:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05505 for ; Wed, 4 Aug 2004 16:20:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74KFJ3m012733; Wed, 4 Aug 2004 13:15:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74KFJ7U012732; Wed, 4 Aug 2004 13:15:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i74KFIIP012717 for ; Wed, 4 Aug 2004 13:15:18 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 10251 invoked by uid 65534); 4 Aug 2004 20:15:17 -0000 Received: from dsl-082-083-160-146.arcor-ip.net (EHLO localhost) (82.83.160.146) by mail.gmx.net (mp009) with SMTP; 04 Aug 2004 22:15:17 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Paul Hoffman / IMC Cc: atom-syntax@imc.org Subject: Re: A simpler proposal: PaceAtomIDAsString Date: Wed, 04 Aug 2004 22:15:11 +0200 Message-ID: <4143430f.959322072@smtp.bjoern.hoehrmann.de> References: <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <413a4850.895131410@smtp.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Paul Hoffman / IMC wrote: >>>>Hmm, it would make more sense to me to specify that the content must >>>>be for example the uc(md5_hex()) of some reasonably unique data >Sorry, I'm confused. I am not proposing making IDs opaque; I thought you were. As far as I can see, the above is a subset of what you propose. Why is "any string" less opaque than "specific strings"? From owner-atom-syntax@mail.imc.org Wed Aug 4 18:49:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16986 for ; Wed, 4 Aug 2004 18:49:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74MeQVH024529; Wed, 4 Aug 2004 15:40:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74MeQru024528; Wed, 4 Aug 2004 15:40:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74MePrT024521 for ; Wed, 4 Aug 2004 15:40:25 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i74MeSvw010407; Wed, 4 Aug 2004 18:40:29 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BLN26192 (AUTH bob@wyman.us); Wed, 4 Aug 2004 18:40:28 -0400 (EDT) Message-Id: <200408042240.BLN26192@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: Cc: "'Sam Ruby'" , "'Atom WG'" , "'David Powell'" Subject: RE: A simpler proposal: PaceAtomIDAsString Date: Wed, 4 Aug 2004 18:40:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR6XbwgiP/l9fEdQrWtaQKXvnHH8AAFTP4Q Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > So one problem is that there actually isn't right > now a terrifically attractive properly-registered > scheme. Would it be acceptable to insert some non-normative text that described how to use a "properly registered" URN scheme, such as urn:publicid, in a way that met Atom's requirements. The non-normative text would: 1. Recommend use of a properly registered scheme such as urn:publicid 2. Note that the combination of domain+date+unique-stuff works well in most cases. 3. Show some examples of "satisfactory" urn:publicid-based identifiers as well as some that are not satisfactory. i.e. urn:publicid:pubsub.com:20040804:example1 is good, urn:publicid:5443234 is bad... bob wyman From owner-atom-syntax@mail.imc.org Wed Aug 4 18:59:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17458 for ; Wed, 4 Aug 2004 18:59:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74MqurW025795; Wed, 4 Aug 2004 15:52:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74MquNQ025794; Wed, 4 Aug 2004 15:52:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-133-150.ietf60.ietf.org [130.129.133.150]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74MqpNT025777; Wed, 4 Aug 2004 15:52:53 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4143430f.959322072@smtp.bjoern.hoehrmann.de> References: <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <413a4850.895131410@smtp.bjoern.hoehrmann.de> <4143430f.959322072@smtp.bjoern.hoehrmann.de> Date: Wed, 4 Aug 2004 15:53:03 -0700 To: Bjoern Hoehrmann From: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Cc: atom-syntax@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:15 PM +0200 8/4/04, Bjoern Hoehrmann wrote: >* Paul Hoffman / IMC wrote: >>>>>Hmm, it would make more sense to me to specify that the content must >>>>>be for example the uc(md5_hex()) of some reasonably unique data > >>Sorry, I'm confused. I am not proposing making IDs opaque; I >>thought you were. > >As far as I can see, the above is a subset of what you propose. Nope, not at all. I didn't say or suggest md5 of anything. >Why is "any string" less opaque than "specific strings"? Again, I'm not understanding what you said. I didn't discuss making the strings opaque in the pace. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 4 19:00:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17568 for ; Wed, 4 Aug 2004 19:00:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74Mqqg3025785; Wed, 4 Aug 2004 15:52:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74MqqFt025784; Wed, 4 Aug 2004 15:52:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (opene-130-129-133-150.ietf60.ietf.org [130.129.133.150]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74MqpNR025777 for ; Wed, 4 Aug 2004 15:52:52 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <51A8DEFD-E646-11D8-B75F-000A95DC3D90@mac.com> References: <1091620281.4110cdb9938a3@webmail.djpowell.net> <4110D71B.3020807@intertwingly.net> <9C803B26-E633-11D8-A4DC-000A95A51C9E@sun.com> <411127E0.8010503@intertwingly.net> <51A8DEFD-E646-11D8-B75F-000A95DC3D90@mac.com> Date: Wed, 4 Aug 2004 15:48:57 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: A simpler proposal: PaceAtomIDAsString Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:44 PM -0400 8/4/04, Graham wrote: >The republisher is wrong for mangling the id. +1 --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 4 19:29:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19230 for ; Wed, 4 Aug 2004 19:29:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74NMx5V027914; Wed, 4 Aug 2004 16:22:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74NMx14027913; Wed, 4 Aug 2004 16:22:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74NMuYC027903 for ; Wed, 4 Aug 2004 16:22:59 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i74NMxvu022313; Wed, 4 Aug 2004 19:23:00 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BLN36249 (AUTH bob@wyman.us); Wed, 4 Aug 2004 19:22:58 -0400 (EDT) Message-Id: <200408042322.BLN36249@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: , "'Atom syntax'" Subject: RE: A simpler proposal: PaceAtomIDAsString Date: Wed, 4 Aug 2004 19:23:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <1091643580.2020.52.camel@homer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR6UmhcayZ27MiiSjGjYdzUe6S/TAAItE7A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave Pawson wrote: > On the evil side, if I choose a really well read blog, and > duplicate their url's as id's, can I 'hack' my way into being > well read? I think "spoofing" is a much more likely "evil thing". Someone could copy the ids of feeds or entries that they didn't like and publish a feed with "alternative" content. They would be hoping that news aggregators would rely on atom:id alone to detect cross-feed duplication of entries or renaming of feeds. If the spoofer uses the id of an "offending" entry but publishes it with a modified-date which is later than that of the version under attack, some aggregators could be tricked into discarding the original messages and replacing it with the spoof entry. Other attacks might rely on guessing the id assignment practices of a feed and then populating another feed with entries that anticipated those to be created in the new feed. In some cases, this could cause aggregators to decide that entries were duplicates or old versions of the spoof entries. There are a variety of flavors to this type of attack. Most should be obvious. > Can we protect against that somehow? Not without some difficulty. Methods include: 1. Relying on digital signatures and various PKI solutions. (i.e. signed ids). 2. Only comparing atom:id's within the scope of a single "source" feed. (i.e. don't support cross feed duplicate detection based on atom:id values alone.) 3. Relying on id assignment schemes that at least ensure that you violate some rule (and potentially law) when you spoof someone. This would mean we'd have to have a registered scheme and we'd have to invest in its use the same kind of "property rights" that are associated with domain names. (This won't eliminate the problem but at least provides some legal sanctions that might discourage casual spoofing.) bob wyman From owner-atom-syntax@mail.imc.org Wed Aug 4 20:38:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24281 for ; Wed, 4 Aug 2004 20:38:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i750TkOZ035014; Wed, 4 Aug 2004 17:29:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i750TkrZ035013; Wed, 4 Aug 2004 17:29:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i750TjZx035006 for ; Wed, 4 Aug 2004 17:29:45 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i750RR53028392 for ; Wed, 4 Aug 2004 18:27:27 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1Y00A916PQL3@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 04 Aug 2004 18:29:50 -0600 (MDT) Received: from [192.168.1.7] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1Y00C2F6PPE1@mail.sun.net> for atom-syntax@imc.org; Wed, 04 Aug 2004 18:29:50 -0600 (MDT) Date: Wed, 04 Aug 2004 17:30:13 -0700 From: Tim Bray Subject: IDSurvey To: "'Atom WG'" Message-id: <9DC43618-E676-11D8-A4DC-000A95A51C9E@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18--458019806; protocol="application/pkcs7-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-18--458019806 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Time for a popularity contest. I think we have *strong*, not rough, consensus on the desired characteristics of atom:id (MUST be there, MUST be globally unique, MUST not change), and I think there's a chance we can rally around any of the syntax choices, assuming we can get the right language in the spec to encourage people to do the right thing. I'd strongly encourage people to go visit http://intertwingly.net/wiki/pie/IDSurvey and record your opinion, because The syntax is not worth investing that much more WG time in at this point. Let's pick one and move on. -Tim --Apple-Mail-18--458019806 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwuKuTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTIyMjMzOTA2WhcNMDUwMTIxMjMzOTA2WjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhR0YnJheUB0ZXh0dWFsaXR5 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMYiIlrf7yTblabXBlwkonodVyp+ W7Oo8w71ErSW7mKramEBAkfkUnPmbRqcS2wqFaK34GbQMk/1vcOxo2AmfmFVec13SWKi0YzXC8xf 9SbjfQU1tXiC9LJB1HeOO46UVRqTNeayruz2pQBztvYF76G5sGmwKjoR/DhimwUM579MaJln38SK UQ6Ya768DwyaDNY7yDWYh1gUxizx71QkzyRCPQdmq6g1ebrVYyoBE33BXQRNGZm2zrlI5JBQ4oax E0Cz3BjR8iZFzK/AhFGDllZYuojf7iZuaNhWr3aWAvHNyLHVMaxXNFb/CUri5c7StFVEgXUVvlgP eSHIPg9gqaECAwEAAaMxMC8wHwYDVR0RBBgwFoEUdGJyYXlAdGV4dHVhbGl0eS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBQAlJ/qQJmtQN966ahSWiovhjWj5Qwk6BnPP+Fjfbo 9guSIWWBw2DEXh8nPT4WJchZSVz4SwDtZ0SZ2PWWToRo/Dmpv+ehzNNhR/y2CdU/zNo+kSShBhc6 HNtp6A0+Yh6Vw0Y+qHa0EKppOJM2D5WTExycYjHU8Xs+dLktAmKqlzCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgwNTAwMzAxM1owIwYJKoZIhvcNAQkEMRYEFC8Z Y6txBNXNMZeesRHUejJ+zwIfMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBAGzj Z+C9vlH+5TV1HsSPuU5cjJH8yrzbP+mPWQWHMyc5GXb/4dMQSJ+7rCEOWB4s1SXiknZPY4c+zCFc udZw2VD+7AnS/2mD3eSKQN3QPeNbM5Oyu7xqKKd8YnthwIya94yxAaU5FvSIAkv+Poc4rb81YH9s 2fI4tK2aQoNuEXFgZZ5Hgjh0/Ba5u2H2Wfz/a5oBOObgtrctMO8tLcir2J9oSH+jGy0dojTy0/8G 9TwP2uKWRWJ1g+JEmtVtkBhHpBna2reEiOVz+l8RzH/CMf1mnkiZXhPzJ2zbPyWRs2vSTnI0NqQ7 n6EHO+pXtc6fIyp+oc9jJCnTPPZ6RjIrI9gAAAAAAAA= --Apple-Mail-18--458019806-- From owner-atom-syntax@mail.imc.org Wed Aug 4 21:23:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26774 for ; Wed, 4 Aug 2004 21:23:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i751H9r7039111; Wed, 4 Aug 2004 18:17:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i751H9vG039110; Wed, 4 Aug 2004 18:17:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i751H8Mx039104 for ; Wed, 4 Aug 2004 18:17:08 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i751HC6g014220 for ; Wed, 4 Aug 2004 21:17:12 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BLN66025 (AUTH bob@wyman.us); Wed, 4 Aug 2004 21:17:11 -0400 (EDT) Message-Id: <200408050117.BLN66025@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom syntax'" Subject: Dates and Time-Sensitive Analysis Applications... Date: Wed, 4 Aug 2004 21:17:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR6ifIluP9v7VC2RsqSz4rGWDNlzQ== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I realize that the date discussion moratorium is still in effect, however, I'd like to point out some uses of dates that I don't think have been considered in the various discussions so far. This is "requirements" and "background" data, not moratorium-prohibited advocacy... Most of the discussion of dates seems to have focused only on dates as used in ordering entries within feeds, displays or lists. However, there are other very interesting uses of dates. For instance, there are a number of applications that explicitly seek "new" entries where "new" means something like "fresh or recent" rather than just "different from what was seen before" or "later than a previous version." Such applications include: 1. Topic Detection and Tracking (TDT)[0] apps: (e.g. popdex.com[1], daypop.com's word[2] or news bursts[3], etc.) 2. Time-sensitive Ranking systems: (e.g Daypop's TopWeblogs[4] or the Link Ranks[5] of PubSub.com ) These applications all rely on some kind of "time-weighted" scoring in an attempt to measure recent activity. Thus, it is important for them to be able to determine not just what is a unique entry but also when the entry was created. Additionally, it is important to be able to identify the date of an entry on a scale which is global (i.e. time zone and use of UTC *is* important). I think that applications like those mentioned above are likely to become important tools in helping people deal with and understand the massive number of entries in the Blogosphere. A specific example of a use for such time-sensitive data can be found at PubSub.com, where we now go beyond simply rating the various blogs with our Link Ranks, we also allow users to use Link Ranks as a means of filtering the set of blogs against which their subscriptions are matched. You can, for instance, say that you only want to receive blog entries that come from those sources which are in the top 1, 2, 5, 10, 25 or 75 percentile of blogs according to Link Rank. Given that Link Ranks are highly date-sensitive; this means that the more you restrict your subscription, the more likely you'll be getting content from "hot" blogs. But, the system only works if we can determine the difference between a new and an old posting. Any of the TDT applications are going to have a similar reliance on accurate date information. The more imprecise the information about when an entry was created, issued, modified or whatever, the harder it is to be precise about what is topical and current. Thus, if we can't get a good solution to the date problem, we're going to find that this class of application will be much less useful to users than it otherwise might be. Anyway, there is much more to dates than simply providing a means of ordering results in an aggregator window... bob wyman [0] http://www.nist.gov/speech/tests/tdt/index.htm [1] http://popdex.com/ [2] http://www.daypop.com/burst/ [3] http://www.daypop.com/newsburst/ [4] http://www.daypop.com/blogrank/ [5] http://www.pubsub.com/linkranks.php From owner-atom-syntax@mail.imc.org Wed Aug 4 22:00:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28659 for ; Wed, 4 Aug 2004 22:00:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i751q5J8041880; Wed, 4 Aug 2004 18:52:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i751q5mO041879; Wed, 4 Aug 2004 18:52:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by above.proper.com (8.12.11/8.12.9) with SMTP id i751q4bd041873 for ; Wed, 4 Aug 2004 18:52:04 -0700 (PDT) (envelope-from meyer_jon@yahoo.com) Message-Id: <200408050152.i751q4bd041873@above.proper.com> Received: from unknown (HELO IBM2950F947866) (meyer?jon@141.155.154.176 with login) by smtp011.mail.yahoo.com with SMTP; 5 Aug 2004 01:52:10 -0000 From: "Jon Meyer" To: , "'Atom syntax'" Subject: RE: Dates and Time-Sensitive Analysis Applications... Date: Wed, 4 Aug 2004 21:52:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <200408050117.BLN66025@ms8.netsolmail.com> Thread-Index: AcR6ifIluP9v7VC2RsqSz4rGWDNlzQAA33oA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On a similar vein, is anyone else out there interested in applying Atom to calendrical events, e.g. a "Whats happening" blog, where entries in the feed correspond to events that will happen? This is similar to future-posting, except you need two dates (start and end). Jon -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Bob Wyman Sent: Wednesday, August 04, 2004 9:17 PM To: 'Atom syntax' Subject: Dates and Time-Sensitive Analysis Applications... I realize that the date discussion moratorium is still in effect, however, I'd like to point out some uses of dates that I don't think have been considered in the various discussions so far. This is "requirements" and "background" data, not moratorium-prohibited advocacy... Most of the discussion of dates seems to have focused only on dates as used in ordering entries within feeds, displays or lists. However, there are other very interesting uses of dates. For instance, there are a number of applications that explicitly seek "new" entries where "new" means something like "fresh or recent" rather than just "different from what was seen before" or "later than a previous version." Such applications include: 1. Topic Detection and Tracking (TDT)[0] apps: (e.g. popdex.com[1], daypop.com's word[2] or news bursts[3], etc.) 2. Time-sensitive Ranking systems: (e.g Daypop's TopWeblogs[4] or the Link Ranks[5] of PubSub.com ) These applications all rely on some kind of "time-weighted" scoring in an attempt to measure recent activity. Thus, it is important for them to be able to determine not just what is a unique entry but also when the entry was created. Additionally, it is important to be able to identify the date of an entry on a scale which is global (i.e. time zone and use of UTC *is* important). I think that applications like those mentioned above are likely to become important tools in helping people deal with and understand the massive number of entries in the Blogosphere. A specific example of a use for such time-sensitive data can be found at PubSub.com, where we now go beyond simply rating the various blogs with our Link Ranks, we also allow users to use Link Ranks as a means of filtering the set of blogs against which their subscriptions are matched. You can, for instance, say that you only want to receive blog entries that come from those sources which are in the top 1, 2, 5, 10, 25 or 75 percentile of blogs according to Link Rank. Given that Link Ranks are highly date-sensitive; this means that the more you restrict your subscription, the more likely you'll be getting content from "hot" blogs. But, the system only works if we can determine the difference between a new and an old posting. Any of the TDT applications are going to have a similar reliance on accurate date information. The more imprecise the information about when an entry was created, issued, modified or whatever, the harder it is to be precise about what is topical and current. Thus, if we can't get a good solution to the date problem, we're going to find that this class of application will be much less useful to users than it otherwise might be. Anyway, there is much more to dates than simply providing a means of ordering results in an aggregator window... bob wyman [0] http://www.nist.gov/speech/tests/tdt/index.htm [1] http://popdex.com/ [2] http://www.daypop.com/burst/ [3] http://www.daypop.com/newsburst/ [4] http://www.daypop.com/blogrank/ [5] http://www.pubsub.com/linkranks.php From owner-atom-syntax@mail.imc.org Wed Aug 4 22:45:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01261 for ; Wed, 4 Aug 2004 22:45:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i752eEHN046581; Wed, 4 Aug 2004 19:40:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i752eEvB046580; Wed, 4 Aug 2004 19:40:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i752eCqf046549 for ; Wed, 4 Aug 2004 19:40:13 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 30400 invoked by uid 65534); 5 Aug 2004 02:40:09 -0000 Received: from dsl-082-083-160-146.arcor-ip.net (EHLO localhost) (82.83.160.146) by mail.gmx.net (mp011) with SMTP; 05 Aug 2004 04:40:09 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Paul Hoffman / IMC Cc: atom-syntax@imc.org Subject: Re: A simpler proposal: PaceAtomIDAsString Date: Thu, 05 Aug 2004 04:39:59 +0200 Message-ID: <41149cd9.982307884@smtp.bjoern.hoehrmann.de> References: <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <12697117.1091575101994.JavaMail.dtcd@mac.com> <41341760.882602775@smtp.bjoern.hoehrmann.de> <411029B8.2070704@dehora.net> <413a4850.895131410@smtp.bjoern.hoehrmann.de> <4143430f.959322072@smtp.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Paul Hoffman / IMC wrote: >>>>>>Hmm, it would make more sense to me to specify that the content must >>>>>>be for example the uc(md5_hex()) of some reasonably unique data >> >>>Sorry, I'm confused. I am not proposing making IDs opaque; I >>>thought you were. >> >>As far as I can see, the above is a subset of what you propose. > >Nope, not at all. I didn't say or suggest md5 of anything. > >>Why is "any string" less opaque than "specific strings"? > >Again, I'm not understanding what you said. I didn't discuss making >the strings opaque in the pace. Sorry but a string without any defined semantics is rather opaque to me. As far as I understand, an element like 9DD4E461268C8034F5C8564E155C67A6 would be legal under both your and my definition, you are saying it is opaque under my definition and not opaque under your definition, that, I am afraid, makes no sense to me at all. So you seem to be saying that this would be non-conforming under your definition, I am however unable to find anything in your Pace that says so. Hence I am lost here. From owner-atom-syntax@mail.imc.org Thu Aug 5 04:15:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02656 for ; Thu, 5 Aug 2004 04:15:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7581J4G026927; Thu, 5 Aug 2004 01:01:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7581J2u026926; Thu, 5 Aug 2004 01:01:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7581Hs9026911 for ; Thu, 5 Aug 2004 01:01:18 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 22036 invoked from network); 5 Aug 2004 08:04:06 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 5 Aug 2004 08:04:06 -0000 Subject: RE: A simpler proposal: PaceAtomIDAsString From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Atom syntax In-Reply-To: <200408041947.BLM62500@ms8.netsolmail.com> References: <200408041947.BLM62500@ms8.netsolmail.com> Content-Type: text/plain Message-Id: <1091692902.2020.6.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 05 Aug 2004 09:01:42 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-04 at 20:47, Bob Wyman wrote: > It seems to me that one way to increase the level of understanding > of how to do things properly would be to provide one of the following: > 1. An example URI scheme (i.e. show a tag or newsml id and discuss > why it meets the requirements of atom. > 2. A recommended URI scheme or schemes (i.e. recommend one or more > of tag, newsml, publicid, etc.) > Would the level of objection to mentioning a specific scheme be > reduced if we only presented the specific scheme or schemes as examples or > recommendations? > Personally, I think it is vital that readers of the spec be exposed > to at least one "satisfactory" scheme before they go off to invent their own > schemes. +1 A clear call for an informative section. Addressing both why, and how (through examples). -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Thu Aug 5 08:28:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14334 for ; Thu, 5 Aug 2004 08:28:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75CFMic091436; Thu, 5 Aug 2004 05:15:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75CFL3f091435; Thu, 5 Aug 2004 05:15:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-relay-4.tiscali.it (mail-relay-4.tiscali.it [213.205.33.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75CFGQt091424 for ; Thu, 5 Aug 2004 05:15:21 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from virgilio.it (62.11.126.81) by mail-relay-4.tiscali.it (7.1.021.3) id 40F3EBEA0061A4E4 for atom-syntax@imc.org; Thu, 5 Aug 2004 14:15:12 +0200 Message-ID: <41122416.2080500@virgilio.it> Date: Thu, 05 Aug 2004 14:12:06 +0200 From: Danny Ayers Reply-To: danny@dannyayers.com User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceBasicAtomID - maybe we're done References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit (still lurking) >>http://intertwingly.net/wiki/pie/PaceBasicAtomID >> >> +1, if I didn't say already. But I don't believe this part : "Significantly increases the ability of feed aggregators and other atom processors to detect and manage new atom entries and feeds." Compared to what, not having IDs? What might significantly increase that ability is the use of (potentially) retrievable http: URIs. Ah well. Cheers, Danny. -- Raw http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Aug 5 10:59:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22694 for ; Thu, 5 Aug 2004 10:59:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75EgwGq003673; Thu, 5 Aug 2004 07:42:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75EgwA9003672; Thu, 5 Aug 2004 07:42:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75EgvWx003653 for ; Thu, 5 Aug 2004 07:42:57 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i75EgZvw001391; Thu, 5 Aug 2004 10:42:37 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BLP75018 (AUTH bob@wyman.us); Thu, 5 Aug 2004 10:42:34 -0400 (EDT) Message-Id: <200408051442.BLP75018@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Jon Meyer'" , "'Atom syntax'" Subject: RE: Dates and Time-Sensitive Analysis Applications... Date: Thu, 5 Aug 2004 10:42:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcR6ifIluP9v7VC2RsqSz4rGWDNlzQAA33oAABptTyA= In-Reply-To: <200408050152.i751q4bd041873@above.proper.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jon Meyer wrote: > is anyone else out there interested in applying Atom to > calendrical events, e.g. a "Whats happening" blog, I think that announcing and maintaining information on events will become an important use for Atom once we're finished working out the blog related issues. My hope is that folk don't go off trying to reinvent the wheel but will, instead, try to stay as close as possible to iCalendar[1], vCard[2] and EventsML[3] when they do this. (Note: EventsML is produced by the IPTC[6], the same folk that maintain the NewsML format.) Also, given the frequently noted similarities between the Atom API and WebDAV[4], one should probably give some thought to Linda Dusseault's proposed CalDAV extensions to WebDav[5]. My personal belief is that every theater (dance, ballet, music, movie, etc.) every organization, every municipal, state and federal government, etc. will one day syndicate detailed information on all of their public events. This will ensure the widest possible dissemination of event information -- something which is not the case today. bob wyman [1] http://www.ietf.org/html.charters/calsch-charter.html (See list of RFC's and ID's at bottom of page above) [2] http://www.ietf.org/rfc/rfc2739.txt [3] http://www.iptc.org/EventsML/ http://groups.yahoo.com/group/eventsml/ [4] http://www.ietf.org/html.charters/webdav-charter.html [5] http://www.rfc-editor.org/internet-drafts/draft-dusseault-caldav-01.txt [6] http://www.iptc.org/pages/index.php From owner-atom-syntax@mail.imc.org Thu Aug 5 11:04:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22904 for ; Thu, 5 Aug 2004 11:04:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75EtZqh004795; Thu, 5 Aug 2004 07:55:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75EtZPs004794; Thu, 5 Aug 2004 07:55:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75EtYfI004784 for ; Thu, 5 Aug 2004 07:55:34 -0700 (PDT) (envelope-from Libby.Miller@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.34) id 1BsjeP-000591-1e; Thu, 05 Aug 2004 15:55:26 +0100 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.34) id 1Bsjbb-000033-TP; Thu, 05 Aug 2004 15:52:33 +0100 Date: Thu, 5 Aug 2004 15:52:31 +0100 (BST) From: Libby Miller X-X-Sender: ecemm@mail.ilrt.bris.ac.uk To: Bob Wyman cc: "'Jon Meyer'" , "'Atom syntax'" Subject: RE: Dates and Time-Sensitive Analysis Applications... In-Reply-To: <200408051442.BLP75018@ms8.netsolmail.com> Message-ID: References: <200408051442.BLP75018@ms8.netsolmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 X-Spam-Level: / Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 5 Aug 2004, Bob Wyman wrote: > > Jon Meyer wrote: >> is anyone else out there interested in applying Atom to >> calendrical events, e.g. a "Whats happening" blog, > I think that announcing and maintaining information on events will > become an important use for Atom once we're finished working out the blog > related issues. > My hope is that folk don't go off trying to reinvent the wheel but > will, instead, try to stay as close as possible to iCalendar[1], vCard[2] note that we have been working on a test-case-based version of iCalendar in RDF: http://www.w3.org/2002/12/cal/ http://esw.w3.org/topic/RdfCalendarDocumentation http://esw.w3.org/topic/RdfCalendarPresentation http://planb.nicecupoftea.org/archives/000769.html If there's a clear demand for it we would be interested in doing an XML profile for this work. We're also thinking right now about documentation for it, so suggestions are welcome (we're aware that the documentation isn't sufficient right now). iCalendar (RFC 2445) isn't suitable for all events, but it is almost sufficient for conferences, cinema listings etc and is used in most personal information management tools, which is why round-tripping from an XML format of icalendar to iCalendar is important (we do this). Libby > and EventsML[3] when they do this. (Note: EventsML is produced by the > IPTC[6], the same folk that maintain the NewsML format.) Also, given the > frequently noted similarities between the Atom API and WebDAV[4], one should > probably give some thought to Linda Dusseault's proposed CalDAV extensions > to WebDav[5]. > My personal belief is that every theater (dance, ballet, music, > movie, etc.) every organization, every municipal, state and federal > government, etc. will one day syndicate detailed information on all of their > public events. This will ensure the widest possible dissemination of event > information -- something which is not the case today. > > bob wyman > > [1] http://www.ietf.org/html.charters/calsch-charter.html > (See list of RFC's and ID's at bottom of page above) > [2] http://www.ietf.org/rfc/rfc2739.txt > [3] http://www.iptc.org/EventsML/ > http://groups.yahoo.com/group/eventsml/ > [4] http://www.ietf.org/html.charters/webdav-charter.html > [5] http://www.rfc-editor.org/internet-drafts/draft-dusseault-caldav-01.txt > [6] http://www.iptc.org/pages/index.php > > > > > > From owner-atom-syntax@mail.imc.org Thu Aug 5 14:13:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03776 for ; Thu, 5 Aug 2004 14:13:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75I09VU020094; Thu, 5 Aug 2004 11:00:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75I09xv020093; Thu, 5 Aug 2004 11:00:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75I06gj020078 for ; Thu, 5 Aug 2004 11:00:07 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i75I0Ail009608 for ; Thu, 5 Aug 2004 12:00:10 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1Z00LZPJC90Q@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 Aug 2004 12:00:10 -0600 (MDT) Received: from [192.168.1.15] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I1Z00CKTJC3E1@mail.sun.net> for atom-syntax@imc.org; Thu, 05 Aug 2004 12:00:04 -0600 (MDT) Date: Thu, 05 Aug 2004 11:00:22 -0700 From: Tim Bray Subject: OK, enough with atom:id To: "'Atom WG'" Cc: Joe Gregorio , Mark Nottingham , Robert Sayre Message-id: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-31--395010876; protocol="application/pkcs7-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-31--395010876 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The survey (http://intertwingly.net/wiki/pie/IDSurvey) is conclusive. We have consensus that atom:id will be canonical URI per http://www.intertwingly.net/wiki/pie/PaceCanonicalIds We also have consensus that we need strong language in our draft that atom:id must be present, globally unique, and immutable (even when an entry moves from category to category or feed to feed or wherever). There is plenty of good candidate language out there on the mailing list and in various Paces. There is lots of room for proposing language for our drafts or an implementors' guide to make atom:id work better. There have been various proposals to recommend some particular URI scheme or URN namespace for Atom; so far no specific scheme/namespace has managed to get anything like rough consensus. Doesn't mean it can't happen, just means it hasn't yet. To our editors: please feel free to go ahead and roll in the consensus language. Sam, there might be a few Paces on the issues list that can now be closed? -Tim --Apple-Mail-31--395010876 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwuKuTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTIyMjMzOTA2WhcNMDUwMTIxMjMzOTA2WjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhR0YnJheUB0ZXh0dWFsaXR5 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMYiIlrf7yTblabXBlwkonodVyp+ W7Oo8w71ErSW7mKramEBAkfkUnPmbRqcS2wqFaK34GbQMk/1vcOxo2AmfmFVec13SWKi0YzXC8xf 9SbjfQU1tXiC9LJB1HeOO46UVRqTNeayruz2pQBztvYF76G5sGmwKjoR/DhimwUM579MaJln38SK UQ6Ya768DwyaDNY7yDWYh1gUxizx71QkzyRCPQdmq6g1ebrVYyoBE33BXQRNGZm2zrlI5JBQ4oax E0Cz3BjR8iZFzK/AhFGDllZYuojf7iZuaNhWr3aWAvHNyLHVMaxXNFb/CUri5c7StFVEgXUVvlgP eSHIPg9gqaECAwEAAaMxMC8wHwYDVR0RBBgwFoEUdGJyYXlAdGV4dHVhbGl0eS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBQAlJ/qQJmtQN966ahSWiovhjWj5Qwk6BnPP+Fjfbo 9guSIWWBw2DEXh8nPT4WJchZSVz4SwDtZ0SZ2PWWToRo/Dmpv+ehzNNhR/y2CdU/zNo+kSShBhc6 HNtp6A0+Yh6Vw0Y+qHa0EKppOJM2D5WTExycYjHU8Xs+dLktAmKqlzCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgwNTE4MDAyMlowIwYJKoZIhvcNAQkEMRYEFMuo nSag8/eBnQzi1lxmP34xni4HMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBAD7O Xb9n1qVu+3eoh1eXyEIB/PUxHlpqmJzJUgZZ5ACvJ5OA/8POdHNdKMpprFcJaGqCYNVPc31f6YXG lNR38VAAC3snDhYUaXwPQJGJyp1vOS29Ey6A6YecfYldYjDt2qiLYDU/mrAIAUnWMLKEGPYiYtz9 9UliK/ytzhciYjx87PRmpCVJHD3SBENnyxK494Bh0iNxiJykl37irB8sxBeHHiSude+owyXOu8UV WuoDOjy+DA/nw9Gqs/FaIr6F8zA8dLx3FnEyXrMZmQJr9OB2VzwyER4vPjUIcdTZeYjj48uULCLj SDweYaDEQ3rGahvty010YAokodO9ccswX40AAAAAAAA= --Apple-Mail-31--395010876-- From owner-atom-syntax@mail.imc.org Thu Aug 5 17:12:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15109 for ; Thu, 5 Aug 2004 17:12:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75L3WoD034949; Thu, 5 Aug 2004 14:03:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75L3WjB034948; Thu, 5 Aug 2004 14:03:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75L3TKB034928 for ; Thu, 5 Aug 2004 14:03:29 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [18.29.0.30]) by homer.w3.org (Postfix) with ESMTP id E015C4F0B0; Thu, 5 Aug 2004 17:03:22 -0400 (EDT) Message-Id: <4.2.0.58.J.20040806055258.05d37a40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 06 Aug 2004 05:57:51 +0900 To: Libby Miller , Bob Wyman From: Martin Duerst Subject: RE: Dates and Time-Sensitive Analysis Applications... Cc: "'Jon Meyer'" , "'Atom syntax'" In-Reply-To: References: <200408051442.BLP75018@ms8.netsolmail.com> <200408051442.BLP75018@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have just attended the meeting of the calsch WG at the IETF in San Diego. Participants, mainly implementers of iCalendar, expressed that there is a need for a new version of the spec that most probably cuts out certain things that have shown to not work well. Journaling and recurring events were mentioned. Regards, Martin. At 15:52 04/08/05 +0100, Libby Miller wrote: >On Thu, 5 Aug 2004, Bob Wyman wrote: > >> >>Jon Meyer wrote: >>>is anyone else out there interested in applying Atom to >>>calendrical events, e.g. a "Whats happening" blog, >> I think that announcing and maintaining information on events will >>become an important use for Atom once we're finished working out the blog >>related issues. >> My hope is that folk don't go off trying to reinvent the wheel but >>will, instead, try to stay as close as possible to iCalendar[1], vCard[2] > >note that we have been working on a test-case-based version of iCalendar >in RDF: > >http://www.w3.org/2002/12/cal/ >http://esw.w3.org/topic/RdfCalendarDocumentation >http://esw.w3.org/topic/RdfCalendarPresentation >http://planb.nicecupoftea.org/archives/000769.html > >If there's a clear demand for it we would be interested in doing an XML >profile for this work. We're also thinking right now about documentation >for it, so suggestions are welcome (we're aware that the documentation >isn't sufficient right now). > >iCalendar (RFC 2445) isn't suitable for all events, but it is almost >sufficient for conferences, cinema listings etc and is used in most >personal information management tools, which is why round-tripping from an >XML format of icalendar to iCalendar is important (we do this). > >Libby > >>and EventsML[3] when they do this. (Note: EventsML is produced by the >>IPTC[6], the same folk that maintain the NewsML format.) Also, given the >>frequently noted similarities between the Atom API and WebDAV[4], one should >>probably give some thought to Linda Dusseault's proposed CalDAV extensions >>to WebDav[5]. >> My personal belief is that every theater (dance, ballet, music, >>movie, etc.) every organization, every municipal, state and federal >>government, etc. will one day syndicate detailed information on all of their >>public events. This will ensure the widest possible dissemination of event >>information -- something which is not the case today. >> >> bob wyman >> >>[1] http://www.ietf.org/html.charters/calsch-charter.html >> (See list of RFC's and ID's at bottom of page above) >>[2] http://www.ietf.org/rfc/rfc2739.txt >>[3] http://www.iptc.org/EventsML/ >> http://groups.yahoo.com/group/eventsml/ >>[4] http://www.ietf.org/html.charters/webdav-charter.html >>[5] http://www.rfc-editor.org/internet-drafts/draft-dusseault-caldav-01.txt >>[6] http://www.iptc.org/pages/index.php >> >> >> >> >> From owner-atom-syntax@mail.imc.org Thu Aug 5 17:38:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16907 for ; Thu, 5 Aug 2004 17:38:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75LWCZa036914; Thu, 5 Aug 2004 14:32:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75LWCf2036913; Thu, 5 Aug 2004 14:32:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [130.129.133.185] (opene-130-129-133-185.ietf60.ietf.org [130.129.133.185]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75LWBj3036906 for ; Thu, 5 Aug 2004 14:32:11 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman Message-Id: Date: Thu, 5 Aug 2004 14:31:10 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Date moratorium next steps Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. Thank you for (mostly) adhering to the moratorium on discussing dates. Hopefully, all of you spent some of this time thinking about what you want and what you really need from dates. (If not, stop reading this, wander around the room a bit, and think.) The next phase of the Great Date Debate will consist of the following: - If you have a good idea of what you need (not want), please write a new pace with a proposal for text for the document. The title of the pace *must* be "PaceDateXyx", where Xyz is a string that indicates one of your names. The purpose of the naming rule is to prevent "PaceDateSimple" or "PaceDateComplete" or "PaceDatePublishingIndustry" and so on. - All elements and/or attributes in each pace *must* have names made up of single lower-case characters, such as "atom:a", "atom:g", and so on. The purpose of the element/attribute naming rule is to force all readers to read the semantics in the pace. The long debate on this list has shown that people (quite naturally) think they know what is in an element by its name; it is unlikely that any one pace will need more than 26 names. - The moratorium on list discussion continues until next Wednesday. At that time, all discussion about dates *must* be about these specific paces. Before Wednesday, do *not* post that "I added a pace" or "Jim's pace looks good" and so on. The purpose of the moratorium extension is to give equal weight to all the proposals, and not to give quick pace-writers the advantage; this is a classic brainstorming technique. - Starting next Wednesday, we talk for a while. If people start to converge, great. If not, polls and so on will happen. The purpose of this is to find consensus. - After we pick one, the pace writer proposes the actual names for the elements and/or attributes and we discuss those on the list. This will hopefully be easy. The purpose of this is to help the document authors. - We find some other thorny issue. --Paul From owner-atom-syntax@mail.imc.org Thu Aug 5 18:08:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19872 for ; Thu, 5 Aug 2004 18:08:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75LxdaJ039245; Thu, 5 Aug 2004 14:59:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75Lxdcd039244; Thu, 5 Aug 2004 14:59:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75LxbhR039238 for ; Thu, 5 Aug 2004 14:59:37 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.146]) by mail.mnot.net (Postfix) with ESMTP id 46369727D; Thu, 5 Aug 2004 14:59:41 -0700 (PDT) In-Reply-To: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Joe Gregorio , "'Atom WG'" , Robert Sayre X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: OK, enough with atom:id Date: Thu, 5 Aug 2004 14:59:35 -0700 To: Tim Bray X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit While respecting that consensus has been determined, I'd like to register my views, since I missed the opportunity beforehand. After reading the (extensive!) threads, my impression is that the use cases for atom:id have not been given due consideration. Namely, no-one has suggested that atom:id be used for anything except identifying whether two instances of a construct (e.g., an atom feed) refer to the same logical thing. Tim did point out that URIs can and often are written on notes, billboards, etc. and copied down. I do not dispute this, but it does not follow that all URIs in all situations are exposed to people (and thus subject to transposition errors). As such, we're using URIs in atom:id as pure identifiers; they're not used to locate anything (e.g., by network access), and they're AFAICT directly copied by machines when they're transposed. If this is the case, it seems that the underlying requirements for atom:id are: - easy to compare two instances to determine if they're the same - easy to make globally unique URIs fit the bill nicely. However, as far as comparison goes, I don't see any reason to add the extra machinery of URI canonicalisation. Doing so adds complexity to the specification and implementations, and introduces a lot of scheme-specific logic. Comparing atom:id as a sequence of characters is much cheaper and simpler. One concern raised about this approach was that implementations that use XML Schema (e.g., Java, C#) would have trouble because they automagically normalise URIs. In fact, I think this is an argument against using canonical URIs, because those implementations' interpretation of URI canonicalisation may not be the same as Atom's, and may diverge over time. Instead, the XML Schema type of atom:id should be xs:string, and its value should be restricted to a URI -- any URI -- by specification prose. Please note that I'm not saying that the current approach won't work -- it will. My objection is that this adds needless complexity to the Atom specification without corresponding benefit, and that it will make some feeds needlessly invalid. If there were use cases where transposition errors of atom:id are likely, I'd be much more amenable to this proposal, but I haven't seen that discussion. Thanks for listening, On Aug 5, 2004, at 11:00 AM, Tim Bray wrote: > The survey (http://intertwingly.net/wiki/pie/IDSurvey) is conclusive. > > We have consensus that atom:id will be canonical URI per > http://www.intertwingly.net/wiki/pie/PaceCanonicalIds > > We also have consensus that we need strong language in our draft that > atom:id must be present, globally unique, and immutable (even when an > entry moves from category to category or feed to feed or wherever). > There is plenty of good candidate language out there on the mailing > list and in various Paces. > > There is lots of room for proposing language for our drafts or an > implementors' guide to make atom:id work better. There have been > various proposals to recommend some particular URI scheme or URN > namespace for Atom; so far no specific scheme/namespace has managed to > get anything like rough consensus. Doesn't mean it can't happen, just > means it hasn't yet. > > To our editors: please feel free to go ahead and roll in the consensus > language. > Sam, there might be a few Paces on the issues list that can now be > closed? -Tim -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Aug 6 13:26:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12251 for ; Fri, 6 Aug 2004 13:26:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76HEQBS041159; Fri, 6 Aug 2004 10:14:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i76HEQqv041158; Fri, 6 Aug 2004 10:14:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76HEOQK041143 for ; Fri, 6 Aug 2004 10:14:24 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail23-en1.mac.com (webmail23-en1 [10.13.10.123]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i76HEHOo023946; Fri, 6 Aug 2004 10:14:17 -0700 (PDT) Received: from webmail23 (localhost.mac.com [127.0.0.1]) by webmail23-en1.mac.com (8.12.6/8.12.6) with ESMTP id i76HEH2O024845; Fri, 6 Aug 2004 10:14:17 -0700 (PDT) Message-ID: <14496243.1091812457192.JavaMail.dtcd@mac.com> Date: Fri, 06 Aug 2004 18:14:17 +0100 From: Graham Parks To: Mark Nottingham Subject: Re: OK, enough with atom:id Cc: Tim Bray , Joe Gregorio , "'Atom WG'" , Robert Sayre in-reply-to: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Abso-frigging-lutely. No to canonicalization, Yes to everything Mark just said. (I didn't bother with the survey because I was busy with other things, and also the stealth re-introduction of voting as "surveys" sucks) Graham From owner-atom-syntax@mail.imc.org Sat Aug 7 16:06:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19957 for ; Sat, 7 Aug 2004 16:06:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77JwJgG069980; Sat, 7 Aug 2004 12:58:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i77JwJtp069979; Sat, 7 Aug 2004 12:58:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77JwI8l069971 for ; Sat, 7 Aug 2004 12:58:18 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i77JwG53013714 for ; Sat, 7 Aug 2004 14:58:17 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i77JwGXl013710; Sat, 7 Aug 2004 14:58:16 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Subject: Re: OK, enough with atom:id References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> From: Ken MacLeod Date: 07 Aug 2004 14:58:16 -0500 In-Reply-To: <14496243.1091812457192.JavaMail.dtcd@mac.com> Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Graham Parks writes: > Abso-frigging-lutely. No to canonicalization, Yes to everything Mark > just said. I'm not sure I understand where the difference is. "Canonical IDs" says the spec text requires a URI and also requires that the URIs be in "canonical" form to enable consumers to use only string comparison level of equivalence. Mark N and Graham seem to be indicating that string equivalence is the goal and that [mentioning | recommending | requiring] canonical IDs to achieve that goal is "less workable". It seems to me the same thing is being stated from two different directions. ** Regardless, I do agree that somewhere it should be noted that the XSD datatype should be "string" and not "URI" to enable string comparison and non-rewriting of URIs by XSD libraries. The spec text prose will still be clear that the content must be a URI and is not an arbitrary string. > (I didn't bother with the survey because I was busy with other > things, and also the stealth re-introduction of voting as "surveys" > sucks) It's not voting. The chairs need a way to determine consensus when it's not clear from the messages themselves. One technique is "straw polls" (Tim may have used "survey" for one fewer wiki words in our case). The difference between voting and a straw poll is that no one "wins" a straw poll simply by quantity of numbers. The chairs still use their reading of the straw poll to help determine where consensus is, and is not. At least that's my current understanding. -- Ken From owner-atom-syntax@mail.imc.org Sun Aug 8 03:19:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04796 for ; Sun, 8 Aug 2004 03:19:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7879l6E060619; Sun, 8 Aug 2004 00:09:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7879lhm060618; Sun, 8 Aug 2004 00:09:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7879kjr060607 for ; Sun, 8 Aug 2004 00:09:47 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7879kil015687 for ; Sun, 8 Aug 2004 01:09:46 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I24008C298AGN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 08 Aug 2004 01:09:46 -0600 (MDT) Received: from [192.168.1.15] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2400E5Q989JC@mail.sun.net> for atom-syntax@imc.org; Sun, 08 Aug 2004 01:09:46 -0600 (MDT) Date: Sun, 08 Aug 2004 00:10:12 -0700 From: Tim Bray Subject: Saskatchewan To: "'Atom WG'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--174821122; protocol="application/pkcs7-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--174821122 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I'm outta here on vacation for a week in the abovementioned place, so if it seems like I'm ignoring the work going on here, I am. Sort those dates out and have fun. -Tim --Apple-Mail-2--174821122 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwuKuTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTIyMjMzOTA2WhcNMDUwMTIxMjMzOTA2WjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhR0YnJheUB0ZXh0dWFsaXR5 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMYiIlrf7yTblabXBlwkonodVyp+ W7Oo8w71ErSW7mKramEBAkfkUnPmbRqcS2wqFaK34GbQMk/1vcOxo2AmfmFVec13SWKi0YzXC8xf 9SbjfQU1tXiC9LJB1HeOO46UVRqTNeayruz2pQBztvYF76G5sGmwKjoR/DhimwUM579MaJln38SK UQ6Ya768DwyaDNY7yDWYh1gUxizx71QkzyRCPQdmq6g1ebrVYyoBE33BXQRNGZm2zrlI5JBQ4oax E0Cz3BjR8iZFzK/AhFGDllZYuojf7iZuaNhWr3aWAvHNyLHVMaxXNFb/CUri5c7StFVEgXUVvlgP eSHIPg9gqaECAwEAAaMxMC8wHwYDVR0RBBgwFoEUdGJyYXlAdGV4dHVhbGl0eS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBQAlJ/qQJmtQN966ahSWiovhjWj5Qwk6BnPP+Fjfbo 9guSIWWBw2DEXh8nPT4WJchZSVz4SwDtZ0SZ2PWWToRo/Dmpv+ehzNNhR/y2CdU/zNo+kSShBhc6 HNtp6A0+Yh6Vw0Y+qHa0EKppOJM2D5WTExycYjHU8Xs+dLktAmKqlzCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgwODA3MTAxMlowIwYJKoZIhvcNAQkEMRYEFEQ9 QGhleiP64vFgC0xM6UOgN/O9MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBAL4f LF7cAQbv5oAEi7TjlAxCdM7nbgIZ+t0dN5SUc6b6+/CLpF+9ApYjGaU8Ql52zPNqqjq8ZXKY1soE mngretC8eoz6LjiFVrxTG/CuuFxNwBj8SHHA7jJZDNFGEHXtTgoNm27fJWhTRhycbGGuw3Ra9oZd TFfC0TsJ71GAkO9qNvGnbEZ8hK9bevE2RVTuuW/v+qRkT0iTAl+npQmIOTHLfhhdswzpFzNETs/T oVNvo7w0YdXZz7PFakO64RiMACRJMDSW/LrFJ4NjYBRzYNIc0dNQj1E/fg7nq9L3Cxi8eX/MsgKt ZWO59XL0om475Rblq32oJzE3SNBCStsttE0AAAAAAAA= --Apple-Mail-2--174821122-- From owner-atom-syntax@mail.imc.org Sun Aug 8 18:40:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17588 for ; Sun, 8 Aug 2004 18:40:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i78MRnkq089474; Sun, 8 Aug 2004 15:27:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i78MRnwx089473; Sun, 8 Aug 2004 15:27:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i78MRm65089465 for ; Sun, 8 Aug 2004 15:27:48 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 24616 invoked from network); 8 Aug 2004 22:27:51 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 8 Aug 2004 22:27:50 -0000 Message-ID: <00cb01c47d96$f0ac5a10$200ca8c0@wkearney.com> From: "Bill Kearney" To: "Micone, Andrew \(Manpower Contract\)" , References: <9836F9167AA283449C82B6D457887E2F2C8A4E@idbexc01.americas.cpqcorp.net> Subject: Re: Binary upload API Was: Options for compound entries Date: Sun, 8 Aug 2004 18:27:50 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Also bearing in mind what one considers 'no good reason' another may consider invaluable for interoperability. I'm all for being as 'bandwidth stingy' as possible when it comes to support devices like cell phones. But I'd much rather see gateway or proxying services be employed to handle this. There are a number of core interoperability issues that may need to be resolved before embarking on more compressed interfacing techniques. As in, make all this stuff work reliably with XML and then, once that's accomplished, seek to establish a profile that maximizes network use. They're both good ideas but it seems the latter won't come without the former. Meanwhile, I'm not finding an well of sympathy for carriers bemoaning 'charges' for bandwidth. If they can't give the customers what they want the customers can and will move to carriers that do. Number portabilily is a wonderful thing. If the providers are so short-sighted as to drive off consumers because of INTEREST in using services, well, they deserve to fail. -Bill Kearney > Keep in mind that what is desirable for the consumer isn't necessarily desirable for the producer or service provider. That 33% overhead from encoding has a real cost associated with it. Multiplied over many mobile devices in a service provider network the cost is substantial. Remember, in general what subscribers pay for their bandwidth doesn't reflect what it costs the provider. The bell curve says that the half of the subscribers who have below average usage will more than pay for those with above average usage. When something throws that out of balance the service provider eats the bandwidth charges and looks for ways to reduce bandwidth usage or passes costs onto the consumer. If the cool new feature on the mobile device inflates bandwidth costs by 33% for no good reason, that's the first place the provider is going to look to improve, lock down, or cost out to the consumer. From owner-atom-syntax@mail.imc.org Sun Aug 8 18:49:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18169 for ; Sun, 8 Aug 2004 18:49:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i78MfiRo090808; Sun, 8 Aug 2004 15:41:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i78MfiSF090807; Sun, 8 Aug 2004 15:41:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i78Mfh7s090782 for ; Sun, 8 Aug 2004 15:41:43 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id PAA15733 for ; Sun, 8 Aug 2004 15:41:41 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id PAA16618 for ; Sun, 8 Aug 2004 15:41:41 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Sun, 08 Aug 2004 15:41:40 -0700 Received: from adsl-64-166-133-244.dsl.snfc21.pacbell.net (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2500D3VGDE5I@shazam.verity.com> for atom-syntax@imc.org; Sun, 08 Aug 2004 15:41:40 -0700 (PDT) Date: Sun, 08 Aug 2004 15:41:49 -0700 From: Walter Underwood X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy Subject: Re: URI equivalence (was Re: PaceFeedEquivalence) In-reply-to: <1E846DCA-E491-11D8-B820-000A95A51C9E@sun.com> To: Atom Syntax Message-id: <97E4FC4DF3BB8F5C2E690657@adsl-64-166-133-244.dsl.snfc21.pacbell.net> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <14be96d30407291338435fdef6@mail.gmail.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <4.2.0.58.J.20040801083942.051f9a88@localhost> <410D307B.9060101@intertwingly.net> <410E47BF.3090106@intertwingly.net> <1E846DCA-E491-11D8-B820-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT --On Monday, August 2, 2004 7:34 AM -0700 Tim Bray wrote: > > If we're going to require canonicalization of atom:id, we could go > further and require all URIs in and so on to be canonicalized, > or at least suggest it with a SHOULD. Makes all sorts of irritating > little problems go away. But then as a spider wrangler, I'm prejudiced :) +1 Spider wranglers of the world, unite! If we require that servers have canonicalization routines for ID, why not use them elsewhere? wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sun Aug 8 19:08:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19056 for ; Sun, 8 Aug 2004 19:08:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i78MpVk1092509; Sun, 8 Aug 2004 15:51:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i78MpVSZ092508; Sun, 8 Aug 2004 15:51:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i78MpUNi092495 for ; Sun, 8 Aug 2004 15:51:30 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id PAA15984 for ; Sun, 8 Aug 2004 15:51:30 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id PAA17129 for ; Sun, 8 Aug 2004 15:51:30 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Sun, 08 Aug 2004 15:51:30 -0700 Received: from adsl-64-166-133-244.dsl.snfc21.pacbell.net (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2500D69GTS5I@shazam.verity.com> for atom-syntax@imc.org; Sun, 08 Aug 2004 15:51:29 -0700 (PDT) Date: Sun, 08 Aug 2004 15:51:38 -0700 From: Walter Underwood X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy Subject: Re: Identity conundrum In-reply-to: To: Atom-Syntax Message-id: <6864D2D52FCC72888646BF1B@adsl-64-166-133-244.dsl.snfc21.pacbell.net> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; charset=iso-8859-1; format=flowed Content-disposition: inline References: <87fz79xt9u.fsf@nwalsh.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i78MpUNi092502 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit --On Sunday, August 1, 2004 9:22 PM +0200 Asbjørn Ulsberg wrote: > > ... a web page or Atom entry representing «Tomorrow's weather reports». I know this is a bit pedantic, but "reports" are measurements of current or past weather and "forecasts" are about the future. Reports don't change ("static resources"), forecasts do ("dynamic resources"). I like the distinction, though I would not say "never change" for general resources. HTML static resources change a lot, with rotating ads, site redesigns, related headlines, while remaining the same resource. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sun Aug 8 20:32:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23081 for ; Sun, 8 Aug 2004 20:32:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i790M6Y1000829; Sun, 8 Aug 2004 17:22:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i790M6VM000828; Sun, 8 Aug 2004 17:22:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i790M5BK000819 for ; Sun, 8 Aug 2004 17:22:05 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id RAA20154 for ; Sun, 8 Aug 2004 17:22:06 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id RAA26761 for ; Sun, 8 Aug 2004 17:22:05 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Sun, 08 Aug 2004 17:22:05 -0700 Received: from adsl-64-166-133-244.dsl.snfc21.pacbell.net (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2500DLDL0R5I@shazam.verity.com> for atom-syntax@imc.org; Sun, 08 Aug 2004 17:22:05 -0700 (PDT) Date: Sun, 08 Aug 2004 17:22:14 -0700 From: Walter Underwood X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy Subject: Re: A simpler proposal: PaceAtomIDAsString In-reply-to: To: Atom WG Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT --On Wednesday, August 4, 2004 10:54 AM -0500 Ken MacLeod wrote: > Paul Hoffman / IMC writes: > >> Greetings again. The earlier thread on atom:id made it clear that >> people really, really want to compare things consistently, and that >> using URIs might get in the way of that. Thus, I have made a >> simplifying proposal at >> . >> >> It explicitly allows URIs for people who want URIs, and allows plain >> text for the rest of us. > > -1 to an "internal (to Atom systems) only" identifier. -1 from me, too. Spiders will see the same content in Atom and non-Atom contexts. An Atom-only ID is of limited use. If the term "metadata crosswalk" is familiar, that is the sort of thing search engines must do, all the time. This applies to IDs, titles, even dates. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sun Aug 8 23:55:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14671 for ; Sun, 8 Aug 2004 23:55:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i793lYvT019438; Sun, 8 Aug 2004 20:47:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i793lYa5019437; Sun, 8 Aug 2004 20:47:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i793lWBW019429 for ; Sun, 8 Aug 2004 20:47:33 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Sun, 8 Aug 2004 20:47:54 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: REMINDER: Date moratorium next steps Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [[ For those of you who thought long and hard about what you needed (not wanted) for dates, Wednesday is the cutoff for paces on the topic. --Paul, the non-vacationing co-chair ]] Greetings again. Thank you for (mostly) adhering to the moratorium on discussing dates. Hopefully, all of you spent some of this time thinking about what you want and what you really need from dates. (If not, stop reading this, wander around the room a bit, and think.) The next phase of the Great Date Debate will consist of the following: - If you have a good idea of what you need (not want), please write a new pace with a proposal for text for the document. The title of the pace *must* be "PaceDateXyx", where Xyz is a string that indicates one of your names. The purpose of the naming rule is to prevent "PaceDateSimple" or "PaceDateComplete" or "PaceDatePublishingIndustry" and so on. - All elements and/or attributes in each pace *must* have names made up of single lower-case characters, such as "atom:a", "atom:g", and so on. The purpose of the element/attribute naming rule is to force all readers to read the semantics in the pace. The long debate on this list has shown that people (quite naturally) think they know what is in an element by its name; it is unlikely that any one pace will need more than 26 names. - The moratorium on list discussion continues until next Wednesday. At that time, all discussion about dates *must* be about these specific paces. Before Wednesday, do *not* post that "I added a pace" or "Jim's pace looks good" and so on. The purpose of the moratorium extension is to give equal weight to all the proposals, and not to give quick pace-writers the advantage; this is a classic brainstorming technique. - Starting next Wednesday, we talk for a while. If people start to converge, great. If not, polls and so on will happen. The purpose of this is to find consensus. - After we pick one, the pace writer proposes the actual names for the elements and/or attributes and we discuss those on the list. This will hopefully be easy. The purpose of this is to help the document authors. - We find some other thorny issue. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Aug 9 00:03:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15238 for ; Mon, 9 Aug 2004 00:03:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i793tmN0021979; Sun, 8 Aug 2004 20:55:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i793tmLR021978; Sun, 8 Aug 2004 20:55:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i793tltM021964 for ; Sun, 8 Aug 2004 20:55:47 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Sun, 8 Aug 2004 20:56:10 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Helping out with canonicalization of URIs Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. In the discussion of PaceCanonicalIds, some questions were brought up about what draft-fielding-uri-rfc2396bis really says about canonicalization. Section 6 of that draft says a few different things. At the URI BOF at the IETF meeting last week, I volunteered the Atompub WG to be reviewers for that document. :-) So, all you canonicalization folks: please review the document, particularly section 6, and send comments to uri@w3.org (archived at ). Just like on this list, if you see something you consider wrong, suggest new text. Your comments will be considered for the soon-to-happen IETF last call on the document. It is likely that we will have to change the wording in PaceCanonicalIds to not say "the rules defined in rfc 2396bis" unless the rules we list exactly match the rules that eventually go into 2369bis. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Aug 9 01:16:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18752 for ; Mon, 9 Aug 2004 01:16:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7953nBj028696; Sun, 8 Aug 2004 22:03:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7953n0M028695; Sun, 8 Aug 2004 22:03:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7953mPs028679 for ; Sun, 8 Aug 2004 22:03:48 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 85368727D; Sun, 8 Aug 2004 22:03:54 -0700 (PDT) In-Reply-To: References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8043536D-E9C1-11D8-8177-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: OK, enough with atom:id Date: Sun, 8 Aug 2004 22:03:49 -0700 To: Ken MacLeod X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What does requiring a canonical URI buy us? On Aug 7, 2004, at 12:58 PM, Ken MacLeod wrote: > > Graham Parks writes: > >> Abso-frigging-lutely. No to canonicalization, Yes to everything Mark >> just said. > > I'm not sure I understand where the difference is. > > "Canonical IDs" says the spec text requires a URI and also requires > that the URIs be in "canonical" form to enable consumers to use only > string comparison level of equivalence. > > Mark N and Graham seem to be indicating that string equivalence is the > goal and that [mentioning | recommending | requiring] canonical IDs to > achieve that goal is "less workable". > > It seems to me the same thing is being stated from two different > directions. > > ** Regardless, I do agree that somewhere it should be noted that the > XSD datatype should be "string" and not "URI" to enable string > comparison and non-rewriting of URIs by XSD libraries. The spec > text prose will still be clear that the content must be a URI and > is not an arbitrary string. > > >> (I didn't bother with the survey because I was busy with other >> things, and also the stealth re-introduction of voting as "surveys" >> sucks) > > It's not voting. The chairs need a way to determine consensus when > it's not clear from the messages themselves. One technique is "straw > polls" (Tim may have used "survey" for one fewer wiki words in our > case). The difference between voting and a straw poll is that no one > "wins" a straw poll simply by quantity of numbers. The chairs still > use their reading of the straw poll to help determine where consensus > is, and is not. At least that's my current understanding. > > -- Ken > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 9 08:47:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26243 for ; Mon, 9 Aug 2004 08:47:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79CcZpf067701; Mon, 9 Aug 2004 05:38:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79CcZKM067700; Mon, 9 Aug 2004 05:38:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79CcYkB067694 for ; Mon, 9 Aug 2004 05:38:34 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i79Ce6r3013526; Mon, 9 Aug 2004 08:40:06 -0400 Message-ID: <4117704D.70503@intertwingly.net> Date: Mon, 09 Aug 2004 08:38:37 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: atom-syntax@imc.org Subject: Re: OK, enough with atom:id References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> <8043536D-E9C1-11D8-8177-000A95BD86C0@mnot.net> In-Reply-To: <8043536D-E9C1-11D8-8177-000A95BD86C0@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: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > What does requiring a canonical URI buy us? http://www.imc.org/atom-syntax/mail-archive/msg08261.html - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 9 09:05:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27071 for ; Mon, 9 Aug 2004 09:05:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79CsV4X068799; Mon, 9 Aug 2004 05:54:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79CsVJw068798; Mon, 9 Aug 2004 05:54:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79CsU1m068792 for ; Mon, 9 Aug 2004 05:54:30 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i79Cu2qF014365; Mon, 9 Aug 2004 08:56:02 -0400 Message-ID: <41177409.1080504@intertwingly.net> Date: Mon, 09 Aug 2004 08:54:33 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: uri@w3.org CC: Atom WG Subject: Re: Helping out with canonicalization of URIs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > Greetings again. In the discussion of PaceCanonicalIds, some questions > were brought up about what draft-fielding-uri-rfc2396bis really says > about canonicalization. Section 6 of that draft says a few different > things. At the URI BOF at the IETF meeting last week, I volunteered the > Atompub WG to be reviewers for that document. :-) > > So, all you canonicalization folks: please review the document, > particularly section 6, and send comments to uri@w3.org (archived at > ). Just like on this list, if > you see something you consider wrong, suggest new text. Your comments > will be considered for the soon-to-happen IETF last call on the document. Excerpts from sections 3 "Syntax Components": foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) Excerpt from section 6.3 "Canonical Form": # Always provide the URI scheme in lowercase characters. # Always provide the host, if any, in lowercase characters. # Only perform percent-encoding where it is essential. # Always use uppercase A-through-F characters when percent-encoding. # Prevent dot-segments appearing in non-relative URI paths. # For schemes that define a default authority, use an empty authority if the default is desired. # For schemes that define an empty path to be equivalent to a path of "/", use "/". These rules completely cover scheme, path, and partially cover authority. Here are some URIs that I can't determine if they are in canonical form based solely on the rules listed in rfc2396-bis: http://:@example.com/ http://example.com:80/ http://example.com/gateway.cgi? http://www.w3.org/2000/01/rdf-schema# My initial inclination would be to declare all of these as non-canonical, but there is enough common practice of the last example that it probably should be an exception. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 9 09:05:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27092 for ; Mon, 9 Aug 2004 09:05:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79CxrRb069109; Mon, 9 Aug 2004 05:59:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Cxreg069108; Mon, 9 Aug 2004 05:59:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79CxqV5069095; Mon, 9 Aug 2004 05:59:53 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i79D1Otg014710; Mon, 9 Aug 2004 09:01:25 -0400 Message-ID: <4117754B.40609@intertwingly.net> Date: Mon, 09 Aug 2004 08:59:55 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: Re: Helping out with canonicalization of URIs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > It is likely that we will have to change the wording in PaceCanonicalIds > to not say "the rules defined in rfc 2396bis" unless the rules we list > exactly match the rules that eventually go into 2369bis. The proposal contained in PaceCanonicalIds does not mention 2369bis. The only mention of 2369bis in the Pace is a mention in the abstract of the Pace itself. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 9 10:34:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02776 for ; Mon, 9 Aug 2004 10:34:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79ENc3T075623; Mon, 9 Aug 2004 07:23:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79ENcfl075622; Mon, 9 Aug 2004 07:23:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79ENZd4075613; Mon, 9 Aug 2004 07:23:35 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4117754B.40609@intertwingly.net> References: <4117754B.40609@intertwingly.net> Date: Mon, 9 Aug 2004 07:16:55 -0700 To: Sam Ruby From: Paul Hoffman / IMC Subject: Re: Helping out with canonicalization of URIs Cc: Atom WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:59 AM -0400 8/9/04, Sam Ruby wrote: >Paul Hoffman / IMC wrote: >> >>It is likely that we will have to change the wording in >>PaceCanonicalIds to not say "the rules defined in rfc 2396bis" >>unless the rules we list exactly match the rules that eventually go >>into 2369bis. > >The proposal contained in PaceCanonicalIds does not mention 2369bis. >The only mention of 2369bis in the Pace is a mention in the abstract >of the Pace itself. Exactly right. If we decide to list the rules for canonicalizing, and those rules don't match whatever comes in 2396bis, we're going to have to note that in our spec. Some developers may be using libraries, and those libraries are likely to be derived from 2396bis. Given the discussion at the BOF on Friday, I don't think that 2396bis will meet our needs, and that we should do our own list. That, plus a note that our list doesn't match 2396bis, should suffice. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Aug 9 11:43:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06959 for ; Mon, 9 Aug 2004 11:43:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79FV5KY081725; Mon, 9 Aug 2004 08:31:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79FV5IL081724; Mon, 9 Aug 2004 08:31:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79FV4h9081718 for ; Mon, 9 Aug 2004 08:31:04 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i79FWY8F022080 for ; Mon, 9 Aug 2004 11:32:37 -0400 Message-ID: <411798B8.8060702@intertwingly.net> Date: Mon, 09 Aug 2004 11:31:04 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: New AtomPubIssuesList for 2004/08/09 References: <4.2.0.58.J.20040729074056.03971e78@localhost> <41083152.4000507@intertwingly.net> In-Reply-To: <41083152.4000507@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList First topic is ids. Relative to syntax: Tim Bray: "I see little dissent"[1], "The syntax is not worth investing that much more WG time in at this point. Let's pick one and move on."[2] and "We have consensus"[3] Despite this we seem to have some concerns [4],[5] over the process, so I am formally including these Paces on today's list. Relative to semantics, we have two paces, PaceRecommendIdScheme and PaceBasicAtomID, both covering similar ground. PacePostLocationMust seems to be a small clarification, unlikely to be very controversial. PaceIntrospection is one that we have seen before, but hasn't made much progress since. It should either be actively worked, accepted, or closed. I've also put PaceProvideSchema and PaceWsdl on the list, not in anticipation that they will be accepted as is. Deciding how we approach this is pivotal to a number of Paces. In particular, I would like to determine the voices advocating SOAP support (example[6]) are looking for SOAP or if WSDL is sufficient. In particular, as WSDL 2.0 is in last call, would the WSDL 2.0 HTTP bindings be acceptable to all? - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg08317.html [2] http://www.imc.org/atom-syntax/mail-archive/msg08309.html [3] http://www.imc.org/atom-syntax/mail-archive/msg08266.html [4] http://www.imc.org/atom-syntax/mail-archive/msg08320.html [5] http://www.imc.org/atom-syntax/mail-archive/msg08321.html [6] http://www.imc.org/atom-syntax/mail-archive/msg07581.html From owner-atom-syntax@mail.imc.org Mon Aug 9 12:12:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08848 for ; Mon, 9 Aug 2004 12:12:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79FrkXs084424; Mon, 9 Aug 2004 08:53:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Frk6D084423; Mon, 9 Aug 2004 08:53:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from jay.songbird.com (jay.songbird.com [208.184.79.253]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79FrkWB084416 for ; Mon, 9 Aug 2004 08:53:46 -0700 (PDT) (envelope-from GK@ninebynine.org) Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id i79FrD010412; Mon, 9 Aug 2004 08:53:17 -0700 Message-Id: <5.1.0.14.2.20040809161019.00b8c930@127.0.0.1> X-Sender: gk-bulk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Aug 2004 16:39:14 +0100 To: Sam Ruby , uri@w3.org From: Graham Klyne Subject: Re: Helping out with canonicalization of URIs Cc: Atom WG In-Reply-To: <41177409.1080504@intertwingly.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 08:54 09/08/04 -0400, Sam Ruby wrote: >These rules completely cover scheme, path, and partially cover authority. >Here are some URIs that I can't determine if they are in canonical form >based solely on the rules listed in rfc2396-bis: I'll offer here my opinions based on my understanding gained from implementing a parser directly from a slightly earlier version of RFC2396bis. (That is, having read and worked with the specification, but without recalling specific assertions in each case.) > http://:@example.com/ I'd say that's different from http://example.com/, in that it contains empty username/password values, which the latter does not. For example, following the exhortation not to expose passwords, my software would (by default) display this as: http://:********@example.com/ whereas the other would be displayed unchanged. (I'm not claiming this is a *useful* distinction, but lacking any text that says a null username/password is the same as having no username/password, I'd say that it does exist.) > http://example.com:80/ I think this is the same as http://example.com/ according to RFC2396bis, but that you have to climb someway up the equivalence ladder (protocol-specific equivalence) to recognize this. It must be expected that many software packages would not recognize this equivalence. (I'm not a great fan of "the ladder" approach, but I don't have anything better to offer...) > http://example.com/gateway.cgi? I'd say this is distinct from http://example.com/gateway.cgi? -- an empty query is not the same as no query at all. > http://www.w3.org/2000/01/rdf-schema# I'd say this is distinct from http://www.w3.org/2000/01/rdf-schema -- an empty fragment is not the same as no fragment at all (note, when used as namespace URI in an RDF document, they certainly would not give rise to the same resource identifiers according to the RDF specifications -- see RDF syntax spec (10 Feb 2004), section 6.1.2, URI accessor) >My initial inclination would be to declare all of these as non-canonical, >but there is enough common practice of the last example that it probably >should be an exception. As you see, I come to different conclusions in most cases. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From owner-atom-syntax@mail.imc.org Mon Aug 9 14:03:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20928 for ; Mon, 9 Aug 2004 14:03:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Hm7kk094901; Mon, 9 Aug 2004 10:48:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Hm7kK094897; Mon, 9 Aug 2004 10:48:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Hm6qs094891 for ; Mon, 9 Aug 2004 10:48:06 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail07.mac.com (webmail07-en1 [10.13.11.149]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i79HlxtR019110; Mon, 9 Aug 2004 10:47:59 -0700 (PDT) Received: from webmail07 (localhost [127.0.0.1]) by webmail07.mac.com (8.12.6/8.12.2) with ESMTP id i79HlxKX019395; Mon, 9 Aug 2004 10:47:59 -0700 (PDT) Message-ID: <5424185.1092073679410.JavaMail.dtcd@mac.com> Date: Mon, 09 Aug 2004 13:47:59 -0400 From: Graham Parks To: Ken MacLeod Subject: Re: OK, enough with atom:id Cc: atom-syntax@imc.org in-reply-to: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, August 07, 2004, at 04:06PM, Ken MacLeod wrote: >"Canonical IDs" says the spec text requires a URI and also requires >that the URIs be in "canonical" form to enable consumers to use only >string comparison level of equivalence. All that's required to do string comparison is that there only be one form of each ID. One way to achieve this is Sam's, where we decide how everyone must canonicalize there URIs. The much more straightforward way is to have the form emitted by the original publisher be the canonical form of that ID. There is absolutely no valid reason for downstream software to change the ID into another form, so this works just as well and doesn't require us to invent or consumers to learn a set of complicated rules. I don't actually see what problems Sam's canonical forms solves. I think the two were: 1) Human error in transcription. While it might correct a small subset of errors, it's not really that useful. There's also very few reasons for humans to be transcribing IDs ever. 2) URI classes that don't preserve exact form. There's no guarantee that these classes will follow the same rules as us, so surely to solve this problem we need to require URI level comparison. Seriously Sam, why are we doing this? Graham From owner-atom-syntax@mail.imc.org Mon Aug 9 14:55:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27012 for ; Mon, 9 Aug 2004 14:55:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Ijo3d002112; Mon, 9 Aug 2004 11:45:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Ijo94002111; Mon, 9 Aug 2004 11:45:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Ijnmc002102 for ; Mon, 9 Aug 2004 11:45:50 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i79IlKSP030695; Mon, 9 Aug 2004 14:47:24 -0400 Message-ID: <4117C65E.9010704@intertwingly.net> Date: Mon, 09 Aug 2004 14:45:50 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: uri@w3.org, Atom WG Subject: Re: Helping out with canonicalization of URIs References: <95383B38-EA31-11D8-8B5A-000393753936@gbiv.com> In-Reply-To: <95383B38-EA31-11D8-8B5A-000393753936@gbiv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > > On Monday, August 9, 2004, at 08:39 AM, Graham Klyne wrote: > >> At 08:54 09/08/04 -0400, Sam Ruby wrote: >> >>> http://:@example.com/ >> >> I'd say that's different from http://example.com/, in that it contains >> empty username/password values, which the latter does not. For >> example, following the exhortation not to expose passwords, my >> software would (by default) display this as: >> http://:********@example.com/ >> whereas the other would be displayed unchanged. >> >> (I'm not claiming this is a *useful* distinction, but lacking any text >> that says a null username/password is the same as having no >> username/password, I'd say that it does exist.) > > Yes, and it is a useful distinction because it defines how the user > agent should respond to an initial authentication request, whereas > without the colon the user agent is not supposed to try authenticating > on its own. A follow up question then, how about: http://@example.com/ > Right, the only thing it might make sense to add is a bullet explicitly > restating what is already said about an empty port in 6.2.3. However, > this is not a conformance issue since all normalization is optional. I would find it to be helpful if a simple statement that empty fragments, queries, passwords (or possibly userinfo) are to be preserved by canonicalization. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 9 15:19:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00818 for ; Mon, 9 Aug 2004 15:19:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79J1wsD003860; Mon, 9 Aug 2004 12:01:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79J1w8K003859; Mon, 9 Aug 2004 12:01:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79J1wva003846 for ; Mon, 9 Aug 2004 12:01:58 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id MAA29231 for ; Mon, 9 Aug 2004 12:01:56 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id MAA28607 for ; Mon, 9 Aug 2004 12:01:56 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 09 Aug 2004 12:01:55 -0700 Received: from air-wunder.verity.com (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2700D3A0V55I@shazam.verity.com> for atom-syntax@imc.org; Mon, 09 Aug 2004 12:01:54 -0700 (PDT) Date: Mon, 09 Aug 2004 12:02:03 -0700 From: Walter Underwood X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy Subject: Re: Helping out with canonicalization of URIs In-reply-to: To: Atom WG Message-id: <7608208E04182D19273B4AA4@[192.168.168.164]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <4117754B.40609@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT --On Monday, August 9, 2004 7:16 AM -0700 "Paul Hoffman / IMC" wrote: > > Given the discussion at the BOF on Friday, I don't think that 2396bis > will meet our needs, and that we should do our own list. That, plus a > note that our list doesn't match 2396bis, should suffice. More custom Atom-only code. Sigh. How do they not meet Atom's needs? wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Aug 9 15:24:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01496 for ; Mon, 9 Aug 2004 15:24:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79JF3kN005302; Mon, 9 Aug 2004 12:15:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79JF3LD005301; Mon, 9 Aug 2004 12:15:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79JF2lb005294 for ; Mon, 9 Aug 2004 12:15:02 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i79JGaeJ031923; Mon, 9 Aug 2004 15:16:37 -0400 Message-ID: <4117CD3B.4070103@intertwingly.net> Date: Mon, 09 Aug 2004 15:15:07 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: atom-syntax@imc.org Subject: Re: OK, enough with atom:id References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> <5424185.1092073679410.JavaMail.dtcd@mac.com> In-Reply-To: <5424185.1092073679410.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > 2) URI classes that don't preserve exact form. There's no guarantee > that these classes will follow the same rules as us, so surely to > solve this problem we need to require URI level comparison. If they produce the URI scheme in uppercase letters, their ids will be flagged as invalid. If they provide the host in uppercase letters, their ids will be flagged as invalid. If they ... etc., etc., etc. = = = What I want is if there are two feeds, one in which an identifier is spelled as a, and in the other it is spelled as a', then the comparison is either deterministic in that *every* clients gets the same result, *or* one or both feeds are declared to be invalid. My fear is that by not precisely defining equivalence, we enable an arms race whereby one implementation uses a normalization rule during comparison, then some feeds are produced that work with that implementation, and then other consumers are required to reverse engineer the rule and implement aggressive canonicalization, etc. Canonicallizing all possible schemes is a large task. By comparison, producers of new entries know what schemes they are producing, generally have only to check a few simple rules (or let the validator do the checking for them), and often they will have to do nothing. Clients, like shrook, also have to do nothing. > Seriously Sam, why are we doing this? http://www.imc.org/atom-syntax/mail-archive/msg08178.html http://www.imc.org/atom-syntax/mail-archive/msg08108.html http://www.imc.org/atom-syntax/mail-archive/msg08194.html - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 9 15:56:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05924 for ; Mon, 9 Aug 2004 15:56:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79JmMh1008859; Mon, 9 Aug 2004 12:48:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79JmMYm008858; Mon, 9 Aug 2004 12:48:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79JmLPC008852 for ; Mon, 9 Aug 2004 12:48:22 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i79Jnrc9000972; Mon, 9 Aug 2004 15:49:56 -0400 Message-ID: <4117D507.7020004@intertwingly.net> Date: Mon, 09 Aug 2004 15:48:23 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom WG Subject: Re: Helping out with canonicalization of URIs References: <4117754B.40609@intertwingly.net> <7608208E04182D19273B4AA4@[192.168.168.164]> In-Reply-To: <7608208E04182D19273B4AA4@[192.168.168.164]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > > --On Monday, August 9, 2004 7:16 AM -0700 "Paul Hoffman / IMC" > wrote: > >> Given the discussion at the BOF on Friday, I don't think that 2396bis >> will meet our needs, and that we should do our own list. That, plus a >> note that our list doesn't match 2396bis, should suffice. > > More custom Atom-only code. Sigh. There certainly will be custom Atom-only code in the feedvalidator, but I would be surprised if you were planning on generating ids with uppercase schemes, mixed case hosts, etc. > How do they not meet Atom's needs? At the moment rfc 2396bis is not as clear as it could be on whether or not empty fragments, queries, passwords (or possibly userinfo) are to be preserved by canonicalization. I'm seeking to get this resolved as a part of last-call, but failing that, I'm soliciting inputs by the spec authors on how such cases should be handled. PaceCanonicalIds will be made consistent with these inputs once they are available. The one case where PaceCanonicalIds goes beyond rfc 2396bis is in requiring utf-8 encoding of non-ASCII characters. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 9 16:32:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12720 for ; Mon, 9 Aug 2004 16:32:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79KKW16012517; Mon, 9 Aug 2004 13:20:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79KKWSD012516; Mon, 9 Aug 2004 13:20:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79KKWXB012506 for ; Mon, 9 Aug 2004 13:20:32 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id NAA10386 for ; Mon, 9 Aug 2004 13:20:31 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id NAA22321 for ; Mon, 9 Aug 2004 13:20:30 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 09 Aug 2004 13:20:28 -0700 Received: from [192.168.150.112] (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2700DQR4I35I@shazam.verity.com> for atom-syntax@imc.org; Mon, 09 Aug 2004 13:20:27 -0700 (PDT) Date: Mon, 09 Aug 2004 13:30:34 -0700 From: Walter Underwood Subject: Re: Helping out with canonicalization of URIs In-reply-to: <4117D507.7020004@intertwingly.net> To: Atom WG Message-id: <6213128BA146EC6FC16148DD@diva.verity.com> MIME-version: 1.0 X-Mailer: Mulberry/3.1.5 (Linux/x86) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <4117754B.40609@intertwingly.net> <7608208E04182D19273B4AA4@[192.168.168.164]> <4117D507.7020004@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT --On Monday, August 09, 2004 03:48:23 PM -0400 Sam Ruby wrote: > > There certainly will be custom Atom-only code in the feedvalidator, but I > would be surprised if you were planning on generating ids with uppercase > schemes, mixed case hosts, etc. I'm thinking about canonical URI throughout Atom, not just IDs. Given the ignorecase filenames on Windows, we see a lot of variant case in the path portion of HTTP URLs. The situation is bad enough that spiders get a decent speedup by ignoring case in all URL paths, even though that is clearly wrong behavior. When every element of a pathname can be UPPER, lower, or Capitalized, a spider can see a large number of URLs for the same resource. Using canonical URIs throughout Atom makes it work better with the rest of the web: caches, bookmarks, search engines, etc. > The one case where PaceCanonicalIds goes beyond rfc 2396bis is in > requiring utf-8 encoding of non-ASCII characters. This is consistent with the (non-normative) recommendation in HTML 4.01: http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.1 Since that is widely implemented, 2396bis really should address it. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon Aug 9 16:49:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15558 for ; Mon, 9 Aug 2004 16:49:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Kcicj013745; Mon, 9 Aug 2004 13:38:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79KcirN013744; Mon, 9 Aug 2004 13:38:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79KchnA013738 for ; Mon, 9 Aug 2004 13:38:43 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id D705D727D; Mon, 9 Aug 2004 13:38:47 -0700 (PDT) In-Reply-To: <4117CD3B.4070103@intertwingly.net> References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> <5424185.1092073679410.JavaMail.dtcd@mac.com> <4117CD3B.4070103@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B3B72FF-EA44-11D8-B442-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org, Graham Parks X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: OK, enough with atom:id Date: Mon, 9 Aug 2004 13:38:44 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit /me bangs head against wall. There seems to be a circular argument here, along the lines of "we need to compensate for different forms of URIs because people might take advantage of the slack we give them to compensate for different forms of URIs..." Why are we giving them the slack? I've heard "robots" and "spiders" mentioned, but I don't find that convincing if Atom IDs are neither to be dereferenced by machines nor transcribed by humans. Can someone walk me through the soup-to-nuts scenario of how a non-canonical URI in an Atom feed causes problems for these use cases, if we specify a simple string comparison function? I've looked at the links Sam has provided and remain unconvinced. Also, > My fear is that by not precisely defining equivalence, we enable an > arms race whereby one implementation uses a normalization rule during > comparison, then some feeds are produced that work with that > implementation, and then other consumers are required to reverse > engineer the rule and implement aggressive canonicalization, etc. I don't think anyone is advocating an imprecise definition of equivalence. My fear is that Atom is going to become complex and convoluted enough to understand that it'll serve as a barrier to adoption. On Aug 9, 2004, at 12:15 PM, Sam Ruby wrote: > > Graham Parks wrote: > >> 2) URI classes that don't preserve exact form. There's no guarantee >> that these classes will follow the same rules as us, so surely to >> solve this problem we need to require URI level comparison. > > If they produce the URI scheme in uppercase letters, their ids will be > flagged as invalid. > > If they provide the host in uppercase letters, their ids will be > flagged as invalid. > > If they ... etc., etc., etc. > > = = = > > What I want is if there are two feeds, one in which an identifier is > spelled as a, and in the other it is spelled as a', > then the comparison is either deterministic in that *every* clients > gets the same result, *or* one or both feeds are declared to be > invalid. > > > > Canonicallizing all possible schemes is a large task. By comparison, > producers of new entries know what schemes they are producing, > generally have only to check a few simple rules (or let the validator > do the checking for them), and often they will have to do nothing. > Clients, like shrook, also have to do nothing. > >> Seriously Sam, why are we doing this? > > http://www.imc.org/atom-syntax/mail-archive/msg08178.html > http://www.imc.org/atom-syntax/mail-archive/msg08108.html > http://www.imc.org/atom-syntax/mail-archive/msg08194.html > > - Sam Ruby > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 9 18:01:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23728 for ; Mon, 9 Aug 2004 18:01:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79LpcP2022277; Mon, 9 Aug 2004 14:51:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Lpc6t022276; Mon, 9 Aug 2004 14:51:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.reutershealth.com ([65.246.141.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79LpbEu022262 for ; Mon, 9 Aug 2004 14:51:37 -0700 (PDT) (envelope-from jcowan@reutershealth.com) Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (Pro-8.9.3/Pro-8.9.3) with SMTP id RAA19734; Mon, 9 Aug 2004 17:44:27 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 9 Aug 2004 17:51:33 -0400 Date: Mon, 9 Aug 2004 17:51:33 -0400 From: John Cowan To: "Clive D.W. Feather" Cc: Graham Klyne , Sam Ruby , uri@w3.org, Atom WG Subject: Re: Helping out with canonicalization of URIs Message-ID: <20040809215132.GG2873@skunk.reutershealth.com> References: <5.1.0.14.2.20040809161019.00b8c930@127.0.0.1> <20040809210350.GC59184@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040809210350.GC59184@finch-staff-1.thus.net> User-Agent: Mutt/1.4.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Clive D.W. Feather scripsit: > HTTP doesn't distinguish them that I can see. Can you explain the RDF bit > in words of one syllable? RDF maps QNames like foo:bar to URI references by appending "bar" to the namespace name currently bound to the prefix foo. It's useful for such namespace names to end in # or /, usually #, so that the local name is clearly separated from the namespace name. -- "But the next day there came no dawn, John Cowan and the Grey Company passed on into the jcowan@reutershealth.com darkness of the Storm of Mordor and were http://www.ccil.org/~cowan lost to mortal sight; but the Dead http://reutershealth.com followed them. --"The Passing of the Grey Company" From owner-atom-syntax@mail.imc.org Mon Aug 9 18:05:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24449 for ; Mon, 9 Aug 2004 18:05:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Lxfar022762; Mon, 9 Aug 2004 14:59:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79LxfB6022761; Mon, 9 Aug 2004 14:59:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79LxecR022755 for ; Mon, 9 Aug 2004 14:59:41 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 6165D4F69E; Mon, 9 Aug 2004 17:59:45 -0400 (EDT) Date: Mon, 9 Aug 2004 17:59:45 -0400 From: Dan Brickley To: Mark Nottingham Cc: Sam Ruby , atom-syntax@imc.org, Graham Parks Subject: Re: OK, enough with atom:id Message-ID: <20040809215945.GC30693@homer.w3.org> References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> <5424185.1092073679410.JavaMail.dtcd@mac.com> <4117CD3B.4070103@intertwingly.net> <1B3B72FF-EA44-11D8-B442-000A95BD86C0@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B3B72FF-EA44-11D8-B442-000A95BD86C0@mnot.net> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm not so worried about the open-endedness of canonicalisation. There is nothing in the URI spec to stop URI schemes overlapping in coverage, for example. The self-same thing might quite reasonably have multiple independent URIs (including urn:* URIs) which name it, and there's nothing we can do to legislate against that, since nobody (thankfully!) has a monopoly on naming. Is this frustrating for completists and perfectionists? you bet. Does it mean that all Atom-spec and URI-spec compliant software might not behave identically? yep. Is it a business opportunity for hardworking canonicalisers? perhaps. A possible source of end-user frustration? certainly... But imho unavoidable if outside of closed world / intranet environments. Canonicalisation *within a URI scheme* might be a more perfectable undertaking, for some schemes, but it's just part of a larger problem. Not a problem that keeps me awake at nights though... Dan From owner-atom-syntax@mail.imc.org Mon Aug 9 18:36:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28297 for ; Mon, 9 Aug 2004 18:36:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79MQOln026387; Mon, 9 Aug 2004 15:26:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79MQOj9026386; Mon, 9 Aug 2004 15:26:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79MQOwQ026380 for ; Mon, 9 Aug 2004 15:26:24 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail13.mac.com (webmail13-en1 [10.13.10.119]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i79MQTRG001985; Mon, 9 Aug 2004 15:26:29 -0700 (PDT) Received: from webmail13 (localhost [127.0.0.1]) by webmail13.mac.com (8.12.6/8.12.2) with ESMTP id i79MQTfC028096; Mon, 9 Aug 2004 15:26:29 -0700 (PDT) Message-ID: <13601528.1092090388861.JavaMail.dtcd@mac.com> Date: Mon, 09 Aug 2004 18:26:28 -0400 From: Graham Parks To: Sam Ruby Subject: Re: OK, enough with atom:id Cc: atom-syntax@imc.org Mime-Version: 1.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: Content-Transfer-Encoding: 7bit On Monday, August 09, 2004, at 03:24PM, Sam Ruby wrote: >My fear is that by not precisely defining equivalence, we enable an arms >race whereby one implementation uses a normalization rule during >comparison, then some feeds are produced that work with that >implementation, and then other consumers are required to reverse >engineer the rule and implement aggressive canonicalization, etc. Well, you and I both define equivalence as by Simple String Comparison, and nothing else (I think), so I'm not sure why that's relevant. >Canonicallizing all possible schemes is a large task. By comparison, >producers of new entries know what schemes they are producing, generally >have only to check a few simple rules (or let the validator do the >checking for them), and often they will have to do nothing. Clients, >like shrook, also have to do nothing. Maybe I'm missing something, but the 2 options are: i) As long as everyone canonicalizes their output, then all strings will be the same and it will all work. ii) As long as everyone makes sure the output is the same as the input, then all strings will be the same and it will all work. The second one looks way more straightforward and elegant and easier to implement. Grahajm From owner-atom-syntax@mail.imc.org Mon Aug 9 18:55:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00075 for ; Mon, 9 Aug 2004 18:55:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Mn4ZN028898; Mon, 9 Aug 2004 15:49:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Mn4j0028897; Mon, 9 Aug 2004 15:49:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Mn3d1028882 for ; Mon, 9 Aug 2004 15:49:03 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id PAA05471 for ; Mon, 9 Aug 2004 15:48:58 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id PAA15755 for ; Mon, 9 Aug 2004 15:47:54 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 09 Aug 2004 15:47:46 -0700 Received: from [192.168.150.112] (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I27000J0BBLUG@shazam.verity.com> for atom-syntax@imc.org; Mon, 09 Aug 2004 15:47:45 -0700 (PDT) Date: Mon, 09 Aug 2004 15:57:53 -0700 From: Walter Underwood Subject: Re: OK, enough with atom:id In-reply-to: <13601528.1092090388861.JavaMail.dtcd@mac.com> To: atom-syntax@imc.org Message-id: <6014E0429CA5F4914983382C@diva.verity.com> MIME-version: 1.0 X-Mailer: Mulberry/3.1.5 (Linux/x86) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <13601528.1092090388861.JavaMail.dtcd@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT --On Monday, August 09, 2004 06:26:28 PM -0400 Graham Parks wrote: > > Maybe I'm missing something, but the 2 options are: > i) As long as everyone canonicalizes their output, then all strings will > be the same and it will all work. > ii) As long as everyone makes sure the output is the same as the input, > then all strings will be the same and it will all work. > > The second one looks way more straightforward and elegant and easier to > implement. But harder to verify as correct. Without the input, it can't be tested at all. The first one can be tested by checking for canonical form. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon Aug 9 19:10:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01373 for ; Mon, 9 Aug 2004 19:10:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79N2c01030146; Mon, 9 Aug 2004 16:02:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79N2cBR030145; Mon, 9 Aug 2004 16:02:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79N2bMc030139 for ; Mon, 9 Aug 2004 16:02:37 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i79N4DS8009934; Mon, 9 Aug 2004 19:04:13 -0400 Message-ID: <41180293.5050009@intertwingly.net> Date: Mon, 09 Aug 2004 19:02:43 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: atom-syntax@imc.org Subject: Re: OK, enough with atom:id References: <13601528.1092090388861.JavaMail.dtcd@mac.com> In-Reply-To: <13601528.1092090388861.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > > Maybe I'm missing something, but the 2 options are: > i) As long as everyone canonicalizes their output, then all strings will be the same and it will all work. > ii) As long as everyone makes sure the output is the same as the input, then all strings will be the same and it will all work. > > The second one looks way more straightforward and elegant and easier to implement. i) and ii) are not mutually exclusive. If you generate new ids, generate them right (lowercase scheme, etc). If you copy valid ids, copy them bit for bit. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 9 19:20:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02434 for ; Mon, 9 Aug 2004 19:20:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79NBpY0030849; Mon, 9 Aug 2004 16:11:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79NBpkM030848; Mon, 9 Aug 2004 16:11:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79NBoCt030842 for ; Mon, 9 Aug 2004 16:11:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i79NBuIV012993; Mon, 9 Aug 2004 16:11:56 -0700 (PDT) Received: from [192.168.241.188] ([216.125.144.129]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i79NBrLv009206; Mon, 9 Aug 2004 16:11:55 -0700 (PDT) In-Reply-To: <41180293.5050009@intertwingly.net> References: <13601528.1092090388861.JavaMail.dtcd@mac.com> <41180293.5050009@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--30701860; protocol="application/pkcs7-signature" Message-Id: <8B1C42D7-EA59-11D8-B7AB-000A95DC3D90@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: Re: OK, enough with atom:id Date: Mon, 9 Aug 2004 18:12:11 -0500 To: Sam Ruby X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-9--30701860 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 9 Aug 2004, at 6:02 pm, Sam Ruby wrote: > i) and ii) are not mutually exclusive. > > If you generate new ids, generate them right (lowercase scheme, etc). > > If you copy valid ids, copy them bit for bit. In which case, what does requiring canonicalization get us except more traffic to your validator? On 9 Aug 2004, at 5:57 pm, Walter Underwood wrote: > But harder to verify as correct. Without the input, it can't be > tested at all. The first one can be tested by checking for > canonical form. So if we have a rule we can test that the rule is being followed? It doesn't get us any closer to testing whether implementations use the same/different IDs at the appropriate time, which is the only thing worth testing for. Graham (PS You two know Glory and Ben are the same person, right?) --Apple-Mail-9--30701860 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODA5MjMxMjExWjAjBgkqhkiG9w0BCQQxFgQUg5aiGrzaNfJYA77ELFd7cUcZ LlMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAfY6oFGs2kabPKE+IGxD2if0u 0ebiRADd0I4BrIARTtiXZgtsKBoTz2Q8VnyT/44Y6h/r6kEBib97K5uTmMsbKxSG5tyaRiY3DttZ dPybbmYDYTlwQyF/eIp550h1up6OtKr7FdX7XLQbPOcQSfCuzSWuHcY+nPhNQo3LmiqwkTyASLLM bc/gpriAaq+WlkXH33PrQYzJVUNMJkDi6jeB7cFO273FyU2Fd2wAzkLSx1YwO1QWkY5HcGz2K+XK 8BpUU7cRBxeMI8TJ6hDW/aDqilz9bybRzWT74SJJztuZd2uXZG2NY3NoFK34jwADaMux6cA1nbyx Q6a1WQcQvOsT2AAAAAAAAA== --Apple-Mail-9--30701860-- From owner-atom-syntax@mail.imc.org Mon Aug 9 20:27:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07406 for ; Mon, 9 Aug 2004 20:27:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0EXAc036066; Mon, 9 Aug 2004 17:14:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A0EXUN036065; Mon, 9 Aug 2004 17:14:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-svc.ntlworld.com (mta10-svc.ntlworld.com [62.253.162.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0EWZB036056 for ; Mon, 9 Aug 2004 17:14:32 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from cpc1-stke1-5-0-cust135.bagu.cable.ntl.com ([81.97.134.135]) by mta10-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040810001311.GTXK10838.mta10-svc.ntlworld.com@cpc1-stke1-5-0-cust135.bagu.cable.ntl.com>; Tue, 10 Aug 2004 01:13:11 +0100 Date: Tue, 10 Aug 2004 01:14:25 +0100 From: David Powell X-Mailer: The Bat! (v2.13 "Lucky" Beta/3) Business Reply-To: David Powell X-Priority: 3 (Normal) Message-ID: <51325445.20040810011425@djpowell.net> To: Sam Ruby CC: Graham Parks , atom-syntax@imc.org Subject: Re: OK, enough with atom:id In-Reply-To: <4117CD3B.4070103@intertwingly.net> References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> <5424185.1092073679410.JavaMail.dtcd@mac.com> <4117CD3B.4070103@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Monday, August 9, 2004, 8:15:07 PM, rubys@intertwingly.net wrote: > Graham Parks wrote: >> Seriously Sam, why are we doing this? > http://www.imc.org/atom-syntax/mail-archive/msg08178.html > http://www.imc.org/atom-syntax/mail-archive/msg08108.html > http://www.imc.org/atom-syntax/mail-archive/msg08194.html I don't buy the argument that Atom spiders will want to "normalize" Atom ids. Web spiders normalize URLs to avoid having to fetch and process the same resource several times. How does this apply to Atom ids? You can't use an atom:id to directly retrieve an entry, so why would an agent want to normalize it? I can understand spiders normalizing the Feed URI, because it is used for retrieval, but there is no reason to normalize the id. If we say now that an Atom identifier requires character-by-character comparison (as Namespaces and RDF do), then a republisher that "normalizes" an atom id is broken. Anyway, a reason not to require canonical URIs: Publishers that have invested in RDF (such as RSS1.0), will have already assigned URI identifiers to their publications. These URIs may or may not fit whatever canonicalization rules that we come up with. If we say that only canonical URIs are allowed, then publishers will have to either change perfectly good ids to be canonicalized (bad), or manage an additional canonicalized alias URI for use in Atom (bad). (I am against requiring a specific URI scheme for ids for the same reason.) I'm not going to push this too hard, I'm sure Atom will work fine whether we require URI canonicalization or not, but not requiring it would save us a big chunk of text in the spec. -- Dave From owner-atom-syntax@mail.imc.org Mon Aug 9 20:37:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08332 for ; Mon, 9 Aug 2004 20:37:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0TuZL037305; Mon, 9 Aug 2004 17:29:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A0Tu1t037304; Mon, 9 Aug 2004 17:29:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0TtKN037298 for ; Mon, 9 Aug 2004 17:29:55 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7A0VWSd014055; Mon, 9 Aug 2004 20:31:32 -0400 Message-ID: <4118170A.9040203@intertwingly.net> Date: Mon, 09 Aug 2004 20:30:02 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax@imc.org Subject: Re: OK, enough with atom:id References: <13601528.1092090388861.JavaMail.dtcd@mac.com> <41180293.5050009@intertwingly.net> <8B1C42D7-EA59-11D8-B7AB-000A95DC3D90@mac.com> In-Reply-To: <8B1C42D7-EA59-11D8-B7AB-000A95DC3D90@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > On 9 Aug 2004, at 6:02 pm, Sam Ruby wrote: > >> i) and ii) are not mutually exclusive. >> >> If you generate new ids, generate them right (lowercase scheme, etc). >> >> If you copy valid ids, copy them bit for bit. > > In which case, what does requiring canonicalization get us except more > traffic to your validator? No, if Tim wants to write a spider that canonicalizes, or somebody accidentally uses one of the classes that was explicitly designed for this purpose that comes with the .Net framework or Java, that too will work. And if things break, we actually can tell what needs to be fixed. "cleanly and thoroughly specified." - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 9 20:46:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09653 for ; Mon, 9 Aug 2004 20:46:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0eEot038133; Mon, 9 Aug 2004 17:40:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A0eEkL038132; Mon, 9 Aug 2004 17:40:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0eEDU038125 for ; Mon, 9 Aug 2004 17:40:14 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7A0eJro003717; Mon, 9 Aug 2004 17:40:19 -0700 (PDT) Received: from [192.168.241.188] ([216.125.144.129]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i7A0eIBA009854; Mon, 9 Aug 2004 17:40:19 -0700 (PDT) In-Reply-To: <4118170A.9040203@intertwingly.net> References: <13601528.1092090388861.JavaMail.dtcd@mac.com> <41180293.5050009@intertwingly.net> <8B1C42D7-EA59-11D8-B7AB-000A95DC3D90@mac.com> <4118170A.9040203@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--25395536; protocol="application/pkcs7-signature" Message-Id: Cc: atom-syntax@imc.org From: Graham Subject: Re: OK, enough with atom:id Date: Mon, 9 Aug 2004 19:40:37 -0500 To: Sam Ruby X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-10--25395536 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 9 Aug 2004, at 7:30 pm, Sam Ruby wrote: > No, if Tim wants to write a spider that canonicalizes, or somebody > accidentally uses one of the classes that was explicitly designed for > this purpose that comes with the .Net framework or Java, that too will > work. And if things break, we actually can tell what needs to be > fixed. > > "cleanly and thoroughly specified." Or it might be easier to tell them DON'T CANONICALIZE YOU FULE. "Is everyone here very stoned?" Graham --Apple-Mail-10--25395536 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODEwMDA0MDM3WjAjBgkqhkiG9w0BCQQxFgQU+qK5lvmuLEUGa2oWyHtd69ct c9EweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEATzFZciXCJ/iZI5aQx+UvSxgS YcO89xd7FWnqQn2sY7UFfrom1sqzHywGpO15HXA3iSfO5v08nQdVrdn30OkBC7HcuTkzI3zTxOu4 7AqLbkjmF5mDm8wIdHcTFZtwS/72Exfx3GQfmN1v7CgRsSzY67MEp1DfJgTH12Nf3/6ivHiuqaFP CuRRWWZ6WqYT23+qZbjPo++fVHK+GeolqP0/ZJJAUfMSjP+tYVr5vc6YuJLf6SaVXn7bk9BBGFzN 8yqhzxKRZmoxwxAq5WEVAIsohdM2F/lnIo9tkEa30RHcwYV53ocpo/hiZrpSV2gTPXrYTYBD+LjP 9yCYg2Al4S8m1wAAAAAAAA== --Apple-Mail-10--25395536-- From owner-atom-syntax@mail.imc.org Mon Aug 9 21:39:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14910 for ; Mon, 9 Aug 2004 21:39:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A1JmPD042827; Mon, 9 Aug 2004 18:19:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A1Jm2Q042826; Mon, 9 Aug 2004 18:19:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A1JkeK042817 for ; Mon, 9 Aug 2004 18:19:47 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Mon, 9 Aug 2004 18:19:30 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Moratorium on atom:id Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. The results at appear to be in conflict with many people posting on the thread titled "OK, enough with atom:id". In specific, almost no one on the survey said they disliked the "canonical URI" proposal, but many folks on this thread are saying that. Oddly, some people on the thread are saying they want something much like my "string" proposal, yet no one other than myself supported it on the survey, and many folks had a dislike. Given these disparities, it's worthwhile for us to just be quiet about this for awhile. When Tim gets back from his vacation, we'll figure out what to do next. In the meantime, let's just let this one lay. Sam, can you move the "currently under discussion" ID paces to "need to revisit", and go ahead and close off the two "recommended for closure" paces? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Aug 9 22:38:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20242 for ; Mon, 9 Aug 2004 22:38:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A2RLZ2050153; Mon, 9 Aug 2004 19:27:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A2RLEH050152; Mon, 9 Aug 2004 19:27:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A2RKc5050146 for ; Mon, 9 Aug 2004 19:27:20 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so212917rnl for ; Mon, 09 Aug 2004 19:27:26 -0700 (PDT) Received: by 10.38.24.64 with SMTP id 64mr1166305rnx; Mon, 09 Aug 2004 19:27:26 -0700 (PDT) Message-ID: <3f1451f50408091927129a05a4@mail.gmail.com> Date: Mon, 9 Aug 2004 22:27:26 -0400 From: Joe Gregorio To: Tim Bray Subject: Re: PaceFeedEquivalence Cc: Martin Duerst , Atom Syntax , Mark Pilgrim In-Reply-To: <6E2041D2-E2A9-11D8-B278-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com> <14be96d30407291338435fdef6@mail.gmail.com> <3f1451f50407292027201f90e1@mail.gmail.com> <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com> <4.2.0.58.J.20040731091629.00b7ba10@localhost> <6E2041D2-E2A9-11D8-B278-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 30 Jul 2004 21:23:53 -0700, Tim Bray wrote: > > On Jul 30, 2004, at 5:21 PM, Martin Duerst wrote: > > > My baseline opinion is still very strongly to only require > > character-by-character (also called codepoint-by-codepoint) > > comparison for ids. This is the one thing that is easiest > > for all implementations to get right. > > I think we're all in agreement that this is all that should be > required. However, we should acknowledge that robots and that class of > software will go further, and while it's not required there's nothing > wrong with that. -Tim No, we shouldn't acknowledge that. The robot/spider argument falls apart when you break it down into its component parts. Why? 1. Robots either know about the Atom format or they don't. 1.1 If a robot knows about Atom then when it finds a URI for the atom:id it will know that it is an id and NOT dereference it but instead use it to identify duplicate entries. [Look at the performace improvement here, we removed an entire HTTP Request.] 1.2 If a robot doesn't know about the Atom format then it will find the URI, perform all the Normalizations you have already discussed, and then proceed to dereference it. [Here the robot, being ignorant of the atom:id, is wasting its time dereferencing an atom:id, but since it is not comparing equivalence of atom entries it. does. not. matter.] So let's just keep the comparison of atom:id's simple by requiring character-by-character comparisons. I would prefer not to complexify the specification for no reason. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Aug 9 23:01:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22280 for ; Mon, 9 Aug 2004 23:01:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A2nU1n053176; Mon, 9 Aug 2004 19:49:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A2nUsa053175; Mon, 9 Aug 2004 19:49:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A2nUWM053169 for ; Mon, 9 Aug 2004 19:49:30 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so153901rnl for ; Mon, 09 Aug 2004 19:49:33 -0700 (PDT) Received: by 10.38.86.74 with SMTP id j74mr948439rnb; Mon, 09 Aug 2004 19:49:33 -0700 (PDT) Message-ID: <3f1451f504080919491a6431d1@mail.gmail.com> Date: Mon, 9 Aug 2004 22:49:33 -0400 From: Joe Gregorio To: Sam Ruby Subject: Re: OK, enough with atom:id Cc: Graham , atom-syntax@imc.org In-Reply-To: <4118170A.9040203@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <13601528.1092090388861.JavaMail.dtcd@mac.com> <41180293.5050009@intertwingly.net> <8B1C42D7-EA59-11D8-B7AB-000A95DC3D90@mac.com> <4118170A.9040203@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 09 Aug 2004 20:30:02 -0400, Sam Ruby wrote: > > Graham wrote: > > > On 9 Aug 2004, at 6:02 pm, Sam Ruby wrote: > > > >> i) and ii) are not mutually exclusive. > >> > >> If you generate new ids, generate them right (lowercase scheme, etc). > >> > >> If you copy valid ids, copy them bit for bit. > > > > In which case, what does requiring canonicalization get us except more > > traffic to your validator? > > No, if Tim wants to write a spider that canonicalizes, or somebody > accidentally uses one of the classes that was explicitly designed for > this purpose that comes with the .Net framework or Java, that too will > work. And if things break, we actually can tell what needs to be fixed. If all feeds are *generated* so that equialent atom:ids are the same character-for-character, than any comparison of them, either character-by-character, or the accidental use of .Net, or Java, will find all the equivalent entries. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Tue Aug 10 00:04:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28321 for ; Tue, 10 Aug 2004 00:04:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A3uGgS060348; Mon, 9 Aug 2004 20:56:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A3uGB0060340; Mon, 9 Aug 2004 20:56:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A3uDFc060287 for ; Mon, 9 Aug 2004 20:56:13 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7A3uK53005856 for ; Mon, 9 Aug 2004 21:56:20 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2700L1JPLVXP@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 09 Aug 2004 21:56:20 -0600 (MDT) Received: from [192.168.1.101] ([24.72.92.157]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2700K33PLJ3N@mail.sun.net> for atom-syntax@imc.org; Mon, 09 Aug 2004 21:56:19 -0600 (MDT) Date: Mon, 09 Aug 2004 20:32:21 -0700 From: Tim Bray Subject: Re: Helping out with canonicalization of URIs In-reply-to: <95383B38-EA31-11D8-8B5A-000393753936@gbiv.com> To: "Roy T. Fielding" Cc: uri@w3.org, Graham Klyne , Sam Ruby , Atom WG Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <95383B38-EA31-11D8-8B5A-000393753936@gbiv.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 9, 2004, at 11:26 AM, Roy T. Fielding wrote: >>> http://example.com:80/ >> >> I think this is the same as http://example.com/ according to >> RFC2396bis, but that you have to climb someway up the equivalence >> ladder (protocol-specific equivalence) to recognize this. It must be >> expected that many software packages would not recognize this >> equivalence. > > It is the same, but that is under scheme-specific normalization, not > protocol. It is the "http" that defines :80/none equivalence, not > HTTP. Agreed; and it would be OK, for example, for Atom to require that you do this, and still be perfectly consistent with 2396bis; but that doesn't mean 2396bis requires it. >>> http://www.w3.org/2000/01/rdf-schema# >> >> I'd say this is distinct from http://www.w3.org/2000/01/rdf-schema -- >> an empty fragment is not the same as no fragment at all (note, when >> used as namespace URI in an RDF document, they certainly would not >> give rise to the same resource identifiers according to the RDF >> specifications -- see RDF syntax spec (10 Feb 2004), section 6.1.2, >> URI accessor) > > Yes. Agreed, and here's another reason why: The semantics of the #fragid are defined in the context of the media type of the representation you get (if you ever get any), and it would be possible, although likely unwise, for some media type to attach semantics to an empty fragment identifier, i.e. example.com/foo# might be *really different* from example.com/foo. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 10 00:45:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01081 for ; Tue, 10 Aug 2004 00:45:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A4Z0oi064055; Mon, 9 Aug 2004 21:35:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A4Z0sw064054; Mon, 9 Aug 2004 21:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A4Yx8C064048 for ; Mon, 9 Aug 2004 21:34:59 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id CC526727D; Mon, 9 Aug 2004 21:35:06 -0700 (PDT) In-Reply-To: <4118170A.9040203@intertwingly.net> References: <13601528.1092090388861.JavaMail.dtcd@mac.com> <41180293.5050009@intertwingly.net> <8B1C42D7-EA59-11D8-B7AB-000A95DC3D90@mac.com> <4118170A.9040203@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Graham , atom-syntax@imc.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: OK, enough with atom:id Date: Mon, 9 Aug 2004 21:35:04 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 9, 2004, at 5:30 PM, Sam Ruby wrote: >> alization get us except more traffic to your validator? > > No, if Tim wants to write a spider that canonicalizes, How exactly would Tim's spider work? Would it merrily canonicalise those URIs just because they're there? Or, are you saying that now we want to be able to dereference atom:id? > or somebody accidentally uses one of the classes that was explicitly > designed for this purpose that comes with the .Net framework or Java, > that too will work. We're now protecting against accidental code misuse in the spec? I'm at a loss. Doing so shifts all of the burden onto people who are authoring the feed. > "cleanly and thoroughly specified." Uh huh. "Mom and apple pie." -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 10 00:48:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01263 for ; Tue, 10 Aug 2004 00:48:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A4e75I064523; Mon, 9 Aug 2004 21:40:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A4e7f0064522; Mon, 9 Aug 2004 21:40:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A4e6ck064509; Mon, 9 Aug 2004 21:40:06 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 151A2727D; Mon, 9 Aug 2004 21:40:14 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5E65108D-EA87-11D8-8047-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Moratorium on atom:id Date: Mon, 9 Aug 2004 21:40:13 -0700 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Paul, Sorry, I didn't see this before the post I just made. Cheers, On Aug 9, 2004, at 6:19 PM, Paul Hoffman / IMC wrote: > > Greetings again. The results at > appear to be in conflict > with many people posting on the thread titled "OK, enough with > atom:id". In specific, almost no one on the survey said they disliked > the "canonical URI" proposal, but many folks on this thread are saying > that. Oddly, some people on the thread are saying they want something > much like my "string" proposal, yet no one other than myself supported > it on the survey, and many folks had a dislike. > > Given these disparities, it's worthwhile for us to just be quiet about > this for awhile. When Tim gets back from his vacation, we'll figure > out what to do next. In the meantime, let's just let this one lay. > > Sam, can you move the "currently under discussion" ID paces to "need > to revisit", and go ahead and close off the two "recommended for > closure" paces? > > --Paul Hoffman, Director > --Internet Mail Consortium > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 10 04:29:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02158 for ; Tue, 10 Aug 2004 04:29:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A8HiMo023532; Tue, 10 Aug 2004 01:17:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A8HijN023531; Tue, 10 Aug 2004 01:17:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A8HhQ2023521 for ; Tue, 10 Aug 2004 01:17:43 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [18.29.0.30]) by homer.w3.org (Postfix) with ESMTP id CBC044F019; Tue, 10 Aug 2004 04:17:42 -0400 (EDT) Message-Id: <4.2.0.58.J.20040810170827.05dbe2f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 10 Aug 2004 17:15:16 +0900 To: Walter Underwood , Atom WG From: Martin Duerst Subject: Re: Helping out with canonicalization of URIs In-Reply-To: <6213128BA146EC6FC16148DD@diva.verity.com> References: <4117D507.7020004@intertwingly.net> <4117754B.40609@intertwingly.net> <7608208E04182D19273B4AA4@[192.168.168.164]> <4117D507.7020004@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 13:30 04/08/09 -0700, Walter Underwood wrote: >--On Monday, August 09, 2004 03:48:23 PM -0400 Sam Ruby > wrote: >> >>There certainly will be custom Atom-only code in the feedvalidator, but I >>would be surprised if you were planning on generating ids with uppercase >>schemes, mixed case hosts, etc. > >I'm thinking about canonical URI throughout Atom, not just IDs. > >Given the ignorecase filenames on Windows, we see a lot of variant >case in the path portion of HTTP URLs. The situation is bad enough >that spiders get a decent speedup by ignoring case in all URL paths, >even though that is clearly wrong behavior. When every element of >a pathname can be UPPER, lower, or Capitalized, a spider can see a >large number of URLs for the same resource. > >Using canonical URIs throughout Atom makes it work better with >the rest of the web: caches, bookmarks, search engines, etc. Are you suggesting that case should be ignored and everything should be canonicalized to lower case in the path part of the URI? >>The one case where PaceCanonicalIds goes beyond rfc 2396bis is in >>requiring utf-8 encoding of non-ASCII characters. > >This is consistent with the (non-normative) recommendation in >HTML 4.01: http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.1 > >Since that is widely implemented, 2396bis really should address it. No, this is not consistent with that specific recommendation. Using IRIs rather than just URIs is consistent with that recommendation. Always requiring %-encoded octets to be in UTF-8 has only partially to do with that recommendation, because that recommendation applies to non-ASCII characters in an attribute, whereas the pace requires %-encoding. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Aug 10 04:33:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02468 for ; Tue, 10 Aug 2004 04:33:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A8HcwH023496; Tue, 10 Aug 2004 01:17:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A8HcGv023495; Tue, 10 Aug 2004 01:17:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A8HbqD023481 for ; Tue, 10 Aug 2004 01:17:38 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [18.29.0.30]) by homer.w3.org (Postfix) with ESMTP id 596744F019; Tue, 10 Aug 2004 04:17:36 -0400 (EDT) Message-Id: <4.2.0.58.J.20040810170522.05a7e498@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 10 Aug 2004 17:07:37 +0900 To: Sam Ruby , Walter Underwood From: Martin Duerst Subject: Re: Helping out with canonicalization of URIs Cc: Atom WG In-Reply-To: <4117D507.7020004@intertwingly.net> References: <7608208E04182D19273B4AA4@[192.168.168.164]> <4117754B.40609@intertwingly.net> <7608208E04182D19273B4AA4@[192.168.168.164]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 15:48 04/08/09 -0400, Sam Ruby wrote: >The one case where PaceCanonicalIds goes beyond rfc 2396bis is in >requiring utf-8 encoding of non-ASCII characters. Why is this required? How is this part of canonicalization? What about schemes that e.g. would explicitly require another encoding? [Note that I'm of course very much for using UTF-8, because that makes things compatible with IRIs, and is a good idea for many other reasons, but forcing this where it is not appropriate does no good.] Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Aug 10 12:02:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06953 for ; Tue, 10 Aug 2004 12:02:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AFnZMR036352; Tue, 10 Aug 2004 08:49:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AFnZEo036351; Tue, 10 Aug 2004 08:49:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AFnWQ9036315 for ; Tue, 10 Aug 2004 08:49:34 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id IAA04383 for ; Tue, 10 Aug 2004 08:49:28 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id IAA29769 for ; Tue, 10 Aug 2004 08:49:26 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Tue, 10 Aug 2004 08:47:14 -0700 Received: from adsl-64-166-133-244.dsl.snfc21.pacbell.net (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2800AZHMBB0M@shazam.verity.com> for atom-syntax@imc.org; Tue, 10 Aug 2004 08:42:49 -0700 (PDT) Date: Tue, 10 Aug 2004 08:42:58 -0700 From: Walter Underwood X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy Subject: Re: Helping out with canonicalization of URIs In-reply-to: <4.2.0.58.J.20040810170827.05dbe2f0@localhost> To: Atom WG Message-id: <1B1B9EC0BEE5A0252F4898B6@adsl-64-166-133-244.dsl.snfc21.pacbell.net> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <4117D507.7020004@intertwingly.net> <4117754B.40609@intertwingly.net> <7608208E04182D19273B4AA4@[192.168.168.164]> <4117D507.7020004@intertwingly.net> <4.2.0.58.J.20040810170827.05dbe2f0@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT --On Tuesday, August 10, 2004 5:15 PM +0900 Martin Duerst wrote: >> >> Given the ignorecase filenames on Windows, we see a lot of variant >> case in the path portion of HTTP URLs. The situation is bad enough >> that spiders get a decent speedup by ignoring case in all URL paths, >> even though that is clearly wrong behavior. When every element of >> a pathname can be UPPER, lower, or Capitalized, a spider can see a >> large number of URLs for the same resource. >> >> Using canonical URIs throughout Atom makes it work better with >> the rest of the web: caches, bookmarks, search engines, etc. > > Are you suggesting that case should be ignored and everything > should be canonicalized to lower case in the path part of the > URI? Huh? How can you read what I said to mean that? I was talking only about spiders, not Atom, and I said it is "clearly wrong behavior". I am describing what spiders currently do, because they must deal with non-canonical URIs. I was *not* proposing that Atom should lowercase URIs. Yuk. My point is that canonical URIs have big advantages where Atom touches the rest of the web, independent of the issues within Atom. Requiring canonicalization of URIs throughout Atom would make Atom a trusted source of URIs for spiders, and would mean that they would not need to do drastic, risky things like lowercasing paths. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 10 15:04:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21393 for ; Tue, 10 Aug 2004 15:04:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AIpE3u056231; Tue, 10 Aug 2004 11:51:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AIpEsc056230; Tue, 10 Aug 2004 11:51:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7AIpC5a056186 for ; Tue, 10 Aug 2004 11:51:13 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 15840 invoked by uid 65534); 10 Aug 2004 18:51:04 -0000 Received: from dsl-213-023-059-248.arcor-ip.net (EHLO localhost) (213.23.59.248) by mail.gmx.net (mp003) with SMTP; 10 Aug 2004 20:51:04 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Walter Underwood Cc: Atom WG Subject: Re: Helping out with canonicalization of URIs Date: Tue, 10 Aug 2004 20:50:50 +0200 Message-ID: <411c1650.1472155077@smtp.bjoern.hoehrmann.de> References: <4117754B.40609@intertwingly.net> <7608208E04182D19273B4AA4@[192.168.168.164]> <4117D507.7020004@intertwingly.net> <6213128BA146EC6FC16148DD@diva.verity.com> In-Reply-To: <6213128BA146EC6FC16148DD@diva.verity.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Walter Underwood wrote: >> The one case where PaceCanonicalIds goes beyond rfc 2396bis is in >> requiring utf-8 encoding of non-ASCII characters. > >This is consistent with the (non-normative) recommendation in >HTML 4.01: http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.1 > >Since that is widely implemented, 2396bis really should address it. It is most certainly not widely implemented, Mozilla Firefox 0.9 does not do anything to this effect at all, MSIE/Win does this only for the path component, etc. From owner-atom-syntax@mail.imc.org Tue Aug 10 15:56:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25971 for ; Tue, 10 Aug 2004 15:56:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJkDDE061661; Tue, 10 Aug 2004 12:46:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AJkDul061647; Tue, 10 Aug 2004 12:46:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJkBKi061615 for ; Tue, 10 Aug 2004 12:46:12 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 813D27C1FB; Tue, 10 Aug 2004 22:39:27 +0200 (CEST) Date: Tue, 10 Aug 2004 22:51:07 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= To: "Tim Bray" Subject: Re: OK, enough with atom:id Cc: Atom-Syntax References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> Message-ID: In-Reply-To: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 05 Aug 2004 11:00:22 -0700, Tim Bray wrote: > To our editors: please feel free to go ahead and roll in the consensus > language. What is the «consensus language», exactly? > Sam, there might be a few Paces on the issues list that can now be > closed? Which ones are those? (Just wondering.) -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Aug 10 15:57:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26329 for ; Tue, 10 Aug 2004 15:57:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJkDkG061662; Tue, 10 Aug 2004 12:46:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AJkDwO061643; Tue, 10 Aug 2004 12:46:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJkBPH061618 for ; Tue, 10 Aug 2004 12:46:12 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 9CFF37C20A; Tue, 10 Aug 2004 22:39:28 +0200 (CEST) Date: Tue, 10 Aug 2004 22:51:08 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= To: "Ken MacLeod" Subject: Re: OK, enough with atom:id Cc: Atom-Syntax References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> <14496243.1091812457192.JavaMail.dtcd@mac.com> Message-ID: Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 07 Aug 2004 14:58:16 -0500, Ken MacLeod wrote: > It's not voting. [...] At least that's my current understanding. Mine as well. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Aug 10 15:57:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26359 for ; Tue, 10 Aug 2004 15:57:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJkDFv061663; Tue, 10 Aug 2004 12:46:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AJkDsj061657; Tue, 10 Aug 2004 12:46:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJkBsB061614; Tue, 10 Aug 2004 12:46:12 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id F028E7C122; Tue, 10 Aug 2004 22:39:26 +0200 (CEST) Date: Tue, 10 Aug 2004 22:51:06 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= To: "Paul Hoffman / IMC" Subject: Re: A simpler proposal: PaceAtomIDAsString Cc: Atom-Syntax References: <20040804043326.29140.qmail@web41213.mail.yahoo.com> Message-ID: Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 4 Aug 2004 09:17:36 -0700, Paul Hoffman / IMC wrote: > No, I copied the text from the current pace. Whether or not people like > the "strings instead of URIs" idea, we can add the proposed suggestion > of "domain + date + extra gunk". Suggesting that the "extra gunk" have > randomness in it might be useful as well. This would be rather nice. Just see how unique RFC 822 MessageID's are, for example. 'MyAggregator:AsbjornUlsberg:2004-08-05:2232@example.com' should be fairly unique, imho. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Aug 10 18:42:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14172 for ; Tue, 10 Aug 2004 18:42:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AMXn3k075143; Tue, 10 Aug 2004 15:33:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AMXnqZ075142; Tue, 10 Aug 2004 15:33:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-68.dsl.pltn13.pacbell.net [66.125.125.68]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AMXiRN075134; Tue, 10 Aug 2004 15:33:45 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <20040804043326.29140.qmail@web41213.mail.yahoo.com> Date: Tue, 10 Aug 2004 15:32:57 -0700 To: =?iso-8859-1?Q?Asbj=F8rn?= Ulsberg From: Paul Hoffman / IMC Subject: MORATORIUM: Re: A simpler proposal: PaceAtomIDAsString Cc: Atom-Syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We're still not talking about dates until tomorrow. That's US time, not European time. :-) --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 10 18:43:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14254 for ; Tue, 10 Aug 2004 18:43:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AMXqWm075151; Tue, 10 Aug 2004 15:33:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AMXqku075150; Tue, 10 Aug 2004 15:33:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-68.dsl.pltn13.pacbell.net [66.125.125.68]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AMXiRP075134; Tue, 10 Aug 2004 15:33:47 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <5203EB29-E709-11D8-A4DC-000A95A51C9E@textuality.com> Date: Tue, 10 Aug 2004 15:33:48 -0700 To: =?iso-8859-1?Q?Asbj=F8rn?= Ulsberg , "Tim Bray" From: Paul Hoffman / IMC Subject: MORATORIUM: Re: OK, enough with atom:id Cc: Atom-Syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We are still not talking about atom:ids for about a week. Tim and I will say when and how to start the discussion again. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 11 00:30:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02901 for ; Wed, 11 Aug 2004 00:30:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B4DUtg007788; Tue, 10 Aug 2004 21:13:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B4DUCA007787; Tue, 10 Aug 2004 21:13:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B4DSFL007781 for ; Tue, 10 Aug 2004 21:13:29 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 10 Aug 2004 21:13:32 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: A more concise round of date proposals Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Greetings again. The cone of silence about dates lifts. We have three good, different proposals for what people think is needed for dates in Atom. Thanks to Asbjørn, Sam, and Antone for putting them together. Please take a look at: In your comments on them, please state what style hat you are wearing (client developer, content aggregator, publisher, and so on) and which you think best fits your needs. It is OK to talk about your wants as well, but please focus on needs, given that this is for the Atom *core* document. And feel free to start threads with appropriate subject lines. This WG tends to not change subject lines often enough. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 11 00:59:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04391 for ; Wed, 11 Aug 2004 00:59:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B4oZOG011961; Tue, 10 Aug 2004 21:50:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B4oZWT011960; Tue, 10 Aug 2004 21:50:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from journurl.com (69-56-184-50.theplanet.com [69.56.184.50] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B4oYGv011950 for ; Tue, 10 Aug 2004 21:50:34 -0700 (PDT) (envelope-from roger@agincourtmedia.com) Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Tue, 10 Aug 2004 23:50:30 -0500 From: "Roger B." To: "'Atom WG'" Subject: PaceDate* Date: Tue, 10 Aug 2004 23:56:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcR/Wd0D4HdUDfpnSou8DW8QNImLUgAAqyFA Message-ID: <229F51DED35841319E2480A3568F71.MAI@journurl.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My role: publishing developer, aggregator developer All three paces meet my absolute needs, since each provides for a date that I can produce and consume, and none of them force me to fill an element with bogus data. PaceDateAsbjornUlsberg: I don't care for flagging atom:d as a SHOULD NOT. Other than that, no major complaints. Minor complaints include the complexity of multiple core date elements. PaceDateSamRuby: My preferred solution. When wearing my feed consuming hat, I just need a date... any date. The freedom to ignore the subtleties of individual publishing systems/processes would be nice. I don't need to know whether the date indicates modification, issuance, creation, or whatever. When wearing my publisher hat, I'm dealing with users who can modify their own feed templates, and can therefore make their own decisions about placing dates inside elements. With Sam's proposal, it's impossible for them to make a mistake when working with the core date element. The other proposals make mistakes inevitable. (Given the complexity of things like Atom's content element, though, this may turn out to be the least of my concerns.) PaceDateAtoneRoundy: A middle ground between the other two, lacking the SHOULD NOT on atom:d. Not my preference, but no major complaints jump out at me. Minor complaints match those for PaceDateAsbjornUlsberg -- Roger Benningfield JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Wed Aug 11 01:36:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05636 for ; Wed, 11 Aug 2004 01:36:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B5S5jY015935; Tue, 10 Aug 2004 22:28:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B5S5ED015934; Tue, 10 Aug 2004 22:28:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailgw.afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B5S2eR015864 for ; Tue, 10 Aug 2004 22:28:03 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.2] (HELO afc.gov.au) by mailgw.afc.gov.au (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1332015 for atom-syntax@imc.org; Wed, 11 Aug 2004 15:27:55 +1000 Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1453265 for atom-syntax@imc.org; Wed, 11 Aug 2004 15:27:55 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 Aug 2004 15:27:28 +1000 Subject: PaceDateAntoneRoundy From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit looks good, mostly. The four date constructs which have semantics of (roughly) [a] date of first issuance/publication [b] date of any modification [c] date of major update as determined by content publisher [d] content related date value hit, I believe, the 80/20 mark. As a publisher, it wouldn't be very difficult to provide all four. Current publishing tools don't support all four at this time, and might have to omit one or two until a software update. As a content consumer via various desktop/webtop aggregators, I need [d] or [a] to put the content into context, and I need [c] rather than [b] to cut through the noise to get to the signal. As an aggregation tool developer, I would need [b] so I know I need to do a full parse & database update. I would need [c] and [d] so I can pass the value on to my users (with [d] it would be via highlighting updated entries). I also like how one date construct is required, rather than atom:entry being larded with lots of date constructs (which for most cases would have the same value, for that matter). Having said all that, the things I don't like: * timezone signal being lost in the wash. I don't really care to infer a geographic location based on timezone, but I may want to know the time as local to the user for additional context. * RFC 3339 doesn't allow for unsynchronised times (ie. without a timezone). As much as we really want to deprecate such things, there is unfortunately a mass of dates already published which don't have timezone data. Given a choice, I'd rather we didn't encourage bad data to masquerade as good data, (while at the same time severely deprecating bad data, of course). * atom:b (date of any modification) has an exclusion of external data ... while the intent is good (for some some value of good), it raises problems. If a feed incorporates external data such as geo:whatever or dc:terms, and the inclusion of that external data is important and fundamental to the feed, then atom:b should be updated even if only that external data is modified. This pace provides atom:c to signal major changes of interest, so a change in atom:b wouldn't necessarily result in a user being bombarded with noise. * the spec text is silent on the significance of "-00:00" as a TZD. e. From owner-atom-syntax@mail.imc.org Wed Aug 11 03:49:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10335 for ; Wed, 11 Aug 2004 03:49:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B7f2PL029939; Wed, 11 Aug 2004 00:41:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B7f2SW029938; Wed, 11 Aug 2004 00:41:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7B7f0Et029921 for ; Wed, 11 Aug 2004 00:41:01 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 16728 invoked from network); 11 Aug 2004 07:44:40 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 11 Aug 2004 07:44:40 -0000 Subject: Re: A more concise round of date proposals From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Atom syntax In-Reply-To: References: Content-Type: text/plain Message-Id: <1092210107.2570.15.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 11 Aug 2004 08:41:47 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-11 at 05:13, Paul Hoffman / IMC wrote: > Greetings again. The cone of silence about dates lifts. > Perspective: Author, reader. +1. Rationale: Simplicity. Easy to understand. Easy to implement. Easy to remember. Follows the KISS principle. Has history. -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Wed Aug 11 11:50:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14011 for ; Wed, 11 Aug 2004 11:50:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFbTVM054530; Wed, 11 Aug 2004 08:37:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BFbTM5054529; Wed, 11 Aug 2004 08:37:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFbS1C054523 for ; Wed, 11 Aug 2004 08:37:28 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7BFbVil019472 for ; Wed, 11 Aug 2004 09:37:31 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2A00JV0GQIR8@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 11 Aug 2004 09:37:31 -0600 (MDT) Received: from [192.168.1.100] ([24.72.92.157]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2A00CZZGQBE4@mail.sun.net> for atom-syntax@imc.org; Wed, 11 Aug 2004 09:37:30 -0600 (MDT) Date: Wed, 11 Aug 2004 08:37:17 -0700 From: Tim Bray Subject: PaceDateSamRuby +1 To: Atom WG Message-id: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT It respects prior art, provides the minimum necessary to declare victory and (this is very important), in my opinion based on observing the discussion to date, it's about the most that we can actually build consensus around. BTW, in my experience "the most you can get consensus around" often turns out to be also "the right answer". -Tim From owner-atom-syntax@mail.imc.org Wed Aug 11 12:37:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17417 for ; Wed, 11 Aug 2004 12:37:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGS9b2060990; Wed, 11 Aug 2004 09:28:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGS9CS060989; Wed, 11 Aug 2004 09:28:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGS8tB060983 for ; Wed, 11 Aug 2004 09:28:08 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7BGSB53021137 for ; Wed, 11 Aug 2004 10:28:11 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I2A00J01J103J@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Wed, 11 Aug 2004 12:28:10 -0400 (EDT) Received: from mercury (vpn-129-150-32-148.Central.Sun.COM [129.150.32.148]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I2A008OTJ2YY8@bur-mail1.east.sun.com> for atom-syntax@imc.org; Wed, 11 Aug 2004 12:28:10 -0400 (EDT) Received: from ndw by mercury with local (Exim 3.36 #1 (Debian)) id 1BuvxN-0007oH-00 for ; Wed, 11 Aug 2004 12:28:05 -0400 X-URL: http://nwalsh.com/ Date: Wed, 11 Aug 2004 12:28:03 -0400 From: Norman Walsh Subject: Re: PaceDateSamRuby +1 In-reply-to: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> To: Atom Syntax Message-id: <87d61xwsfg.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain / Tim Bray was heard to say: | It respects prior art, provides the minimum necessary to declare | victory and (this is very important), in my opinion based on observing | the discussion to date, it's about the most that we can actually build | consensus around. BTW, in my experience "the most you can get | consensus around" often turns out to be also "the right answer". -Tim +1 Be seeing you, norm -- Norman Walsh | Almost every man wastes part of his http://nwalsh.com/ | life in attempts to display qualities | which he does not possess, and to gain | applause which he cannot keep.--Dr. | Johnson --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBGkkUOyltUcwYWjsRAilXAKCaKQZIYWQLekF0cpPvFGZ8I9PC8wCdHva1 4dPGmN4mBQvRPk0vq/jw6s0= =xfN7 -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Aug 11 13:00:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19059 for ; Wed, 11 Aug 2004 13:00:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGkrvE063519; Wed, 11 Aug 2004 09:46:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGkrow063518; Wed, 11 Aug 2004 09:46:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41208.mail.yahoo.com (web41208.mail.yahoo.com [66.218.93.41]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BGkqYq063509 for ; Wed, 11 Aug 2004 09:46:52 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040811164646.3465.qmail@web41208.mail.yahoo.com> Received: from [67.160.84.159] by web41208.mail.yahoo.com via HTTP; Wed, 11 Aug 2004 09:46:46 PDT Date: Wed, 11 Aug 2004 09:46:46 -0700 (PDT) From: Dare Obasanjo Subject: PaceDateAsbjornUlsberg -1 To: atom-syntax@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From my perspective as an aggregator developer this seems like way too many dates and the semantics of some of them confused me (especially the subtle difference between atom:b & atom:c). I can't think of which of the dates my application should depend on. PS: Stylistically I have issues with the fact that the Pace references http://msdn.microsoft.com/library/en-us/dndotnet/html/datetimecode.asp which is mainly a guide to all the gotchas surrounding the DateTime class in the .NET Framework. I'm not sure how it is generally relevant to developers at large that aren't using the .NET Framework. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 11 13:04:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19272 for ; Wed, 11 Aug 2004 13:04:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGupNN064307; Wed, 11 Aug 2004 09:56:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGuprD064306; Wed, 11 Aug 2004 09:56:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BGuojZ064294 for ; Wed, 11 Aug 2004 09:56:50 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040811165649.54180.qmail@web41207.mail.yahoo.com> Received: from [67.160.84.159] by web41207.mail.yahoo.com via HTTP; Wed, 11 Aug 2004 09:56:49 PDT Date: Wed, 11 Aug 2004 09:56:49 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateSamRuby +1 To: Norman Walsh , Atom Syntax In-Reply-To: <87d61xwsfg.fsf@nwalsh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Norman Walsh wrote: > / Tim Bray was heard to say: > | It respects prior art, provides the minimum > necessary to declare > | victory and (this is very important), in my > opinion based on observing > | the discussion to date, it's about the most that > we can actually build > | consensus around. BTW, in my experience "the most > you can get > | consensus around" often turns out to be also "the > right answer". -Tim > > +1 +1 ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 11 13:05:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19324 for ; Wed, 11 Aug 2004 13:05:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGtsLU064245; Wed, 11 Aug 2004 09:55:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGtsV7064244; Wed, 11 Aug 2004 09:55:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BGtsZu064230 for ; Wed, 11 Aug 2004 09:55:54 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040811165547.12731.qmail@web41210.mail.yahoo.com> Received: from [67.160.84.159] by web41210.mail.yahoo.com via HTTP; Wed, 11 Aug 2004 09:55:47 PDT Date: Wed, 11 Aug 2004 09:55:47 -0700 (PDT) From: Dare Obasanjo Subject: PaceDateAntoneRoundy -1 To: atom-syntax@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: My perspective is as a developer of a desktop aggregator. I don't like having both atom:b and atom:c in the format since the distinction seems to not be useful to client applications like mine. I especially don't like the special casing of advertisements in the description of atom:b since it seems like an arbitrary item to special-case. I'd use atom:a but the fact that atom:d exists points to an area of potential ambiguity if they both exist on an entry. Don't like this pace. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 11 13:14:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19774 for ; Wed, 11 Aug 2004 13:14:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BH3wrB064837; Wed, 11 Aug 2004 10:03:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BH3w5H064836; Wed, 11 Aug 2004 10:03:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BH3wJs064828 for ; Wed, 11 Aug 2004 10:03:58 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7BH40ro018530; Wed, 11 Aug 2004 10:04:00 -0700 (PDT) Received: from [192.168.241.188] ([216.125.144.129]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i7BH3xfs013723; Wed, 11 Aug 2004 10:03:59 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-27-120026396; protocol="application/pkcs7-signature" Message-Id: <7C26F841-EBB8-11D8-B7AB-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceDateAntoneRoundy Date: Wed, 11 Aug 2004 12:04:19 -0500 To: Eric Scheid X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-27-120026396 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 11 Aug 2004, at 12:27 am, Eric Scheid wrote: > The four date constructs which have semantics of (roughly) > > [a] date of first issuance/publication > [b] date of any modification > [c] date of major update as determined by content publisher > [d] content related date value > > hit, I believe, the 80/20 mark. Make atom:a a MUST, flesh out the text a bit, absolutely perfect. Graham --Apple-Mail-27-120026396 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODExMTcwNDE5WjAjBgkqhkiG9w0BCQQxFgQUEJ3W57pEM8T7n9QCsdq9Ryv2 GqsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAsBkHOfU8LbaNXtxREvkM8C1D 7DuyIJtuUufetwHj3K2yZuHRFnV5C7IUqBnea9mKrHU/VEdN+0cvuy0YByinlB4e1eGMSvL6hqvM 8LJibUidry0W2m8A/MO8zv4P3DjJdPrECJAEigs/qH3z6NkJGaZuI1wghxi4b4bvk5CbycEtTei0 g4YtK2Mi+yvKFK6GLNGvsBNXSqyNMnfp/k+ltVT83Po8dDKUFLcVYrxAWOSHuldDSsqm6VWLVDc7 rRDgh/oYAsnadU5bL9lUDMMiAOy8Xe4KPEcMZ8vSrihcqegAtHr2sxFpresSCG5Cjx4aMRLCtirN /nf/j538i68QFQAAAAAAAA== --Apple-Mail-27-120026396-- From owner-atom-syntax@mail.imc.org Wed Aug 11 13:22:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20473 for ; Wed, 11 Aug 2004 13:22:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BH6ixW065134; Wed, 11 Aug 2004 10:06:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BH6iPl065133; Wed, 11 Aug 2004 10:06:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BH6i6i065127 for ; Wed, 11 Aug 2004 10:06:44 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7BH6lfO003556 for ; Wed, 11 Aug 2004 10:06:47 -0700 (PDT) Received: from [192.168.241.188] ([216.125.144.129]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i7BH6kQ4009075 for ; Wed, 11 Aug 2004 10:06:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <87d61xwsfg.fsf@nwalsh.com> References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> <87d61xwsfg.fsf@nwalsh.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-28-120195094; protocol="application/pkcs7-signature" Message-Id: From: Graham Subject: Re: PaceDateSamRuby -1 Date: Wed, 11 Aug 2004 12:07:08 -0500 To: Atom Syntax X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-28-120195094 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Differing interpretations of the DC spec as regards Atom + different expected behavior + people trying to be clever = my definition of interoperability hell (And lots of new convoluted date code in Shrook that doesn't actually work all of the time, presumably) "cleanly and thoroughly specified" Graham --Apple-Mail-28-120195094 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODExMTcwNzA4WjAjBgkqhkiG9w0BCQQxFgQULz/bngCLoXQhcoHG0H+Tb+C5 rEoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAIibllncjLCQRwEPEKPMKi3KE uHUTbE88ZcDvNyPQA2FmANblpTa4aiowfsJ1sDeUGsXYeOpElnamHoLW+BnZMk9RISe4JcdqlHtc lBz78INQHcpY3UGLQxg6CVyPSbzaoOwj4QccHe+PQAO6/RMPBrdNVhhOAVEwEUzU6FQ8+9hIPbD+ ZqITDP5SaefWJwR2XCrNkXO6/wp7mPtQojvpYKJwN9lc1+wBUemek9vKYEAn2LNwGGX8yinYRpVs uKmFrhl/R7/VLEj/7UcakLY8ynWgbWqj9ohOAYKFSjRB1xqy9I46thVmoUjdhc9N/osPgokVMb1w 09vLzBftWSGqdgAAAAAAAA== --Apple-Mail-28-120195094-- From owner-atom-syntax@mail.imc.org Wed Aug 11 13:28:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20896 for ; Wed, 11 Aug 2004 13:28:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHKgo2066730; Wed, 11 Aug 2004 10:20:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BHKgh9066729; Wed, 11 Aug 2004 10:20:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHKeXq066706 for ; Wed, 11 Aug 2004 10:20:41 -0700 (PDT) (envelope-from eliast@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so250664rnk for ; Wed, 11 Aug 2004 10:20:35 -0700 (PDT) Received: by 10.38.70.22 with SMTP id s22mr547540rna; Wed, 11 Aug 2004 10:20:35 -0700 (PDT) Message-ID: <905f7c91040811102036c66207@mail.gmail.com> Date: Wed, 11 Aug 2004 13:20:35 -0400 From: Elias Torres Reply-To: elias@torrez.us To: Dare Obasanjo Subject: Re: PaceDateSamRuby +1 Cc: Norman Walsh , Atom Syntax In-Reply-To: <20040811165649.54180.qmail@web41207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040811165649.54180.qmail@web41207.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 I like it too, but I thought Atom WG was not too comfortable with bringing items from DC into the spec? i.e. not using dc:title and using atom:title, etc, etc. On Wed, 11 Aug 2004 09:56:49 -0700 (PDT), Dare Obasanjo wrote: > > > --- Norman Walsh wrote: > > > / Tim Bray was heard to say: > > | It respects prior art, provides the minimum > > necessary to declare > > | victory and (this is very important), in my > > opinion based on observing > > | the discussion to date, it's about the most that > > we can actually build > > | consensus around. BTW, in my experience "the most > > you can get > > | consensus around" often turns out to be also "the > > right answer". -Tim > > > > +1 > > +1 > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 > No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - 100MB free storage! > http://promotions.yahoo.com/new_mail > > From owner-atom-syntax@mail.imc.org Wed Aug 11 13:38:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21373 for ; Wed, 11 Aug 2004 13:38:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHOuRu067427; Wed, 11 Aug 2004 10:24:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BHOuxR067426; Wed, 11 Aug 2004 10:24:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHOuZs067419 for ; Wed, 11 Aug 2004 10:24:56 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7BHOxRG026925; Wed, 11 Aug 2004 10:24:59 -0700 (PDT) Received: from [192.168.241.188] ([216.125.144.129]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i7BHOvfs020960; Wed, 11 Aug 2004 10:24:58 -0700 (PDT) In-Reply-To: <20040811165547.12731.qmail@web41210.mail.yahoo.com> References: <20040811165547.12731.qmail@web41210.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-30-121285680; protocol="application/pkcs7-signature" Message-Id: <6ABE8B52-EBBB-11D8-B7AB-000A95DC3D90@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: Re: PaceDateAntoneRoundy -1 Date: Wed, 11 Aug 2004 12:25:18 -0500 To: Dare Obasanjo X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-30-121285680 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 11 Aug 2004, at 11:55 am, Dare Obasanjo wrote: > My perspective is as a developer of a desktop > aggregator. I don't like having both atom:b and atom:c > in the format since the distinction seems to not be > useful to client applications like mine. I think it might be supremely useful - and anyway, why can't you just ignore them in your program? > I especially > don't like the special casing of advertisements in the > description of atom:b since it seems like an arbitrary > item to special-case. I'm not sure it should be in the final spec text - but do you agree in principal? > I'd use atom:a but the fact that atom:d exists points > to an area of potential ambiguity if they both exist > on an entry. Figure out whether you want RSSBandit to sort by (or display): a) The date the entry was published d) The date the entry has been labeled with Answer that question, and there's no ambiguity when both exist. Graham --Apple-Mail-30-121285680 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODExMTcyNTE5WjAjBgkqhkiG9w0BCQQxFgQUTjg70TaItMsUWkCI5TpsSo4F kKkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEASUqUeD/jwDnPT3+7Dec+y2UT oDwv8cy6u4+reWne54w0QBKDTqjqwhD1/94IadYIRtG+42xM2z0izBI12SZvoch8HguWypu6tVzQ bCPYq6tpVusbO2hlffxR6Wk3dBGNsdIsxr/9dvaCMzFzrpqEYsf5G0PEZR4f9VkhrOW0SiQtH4qV mRro+sCeViPOJlaonXmKNNJCsLUCiVjkPTFXeEdr2W0bLV2I4kYFjnJ4hnT1jObVesN+/jYI2olJ JB/htB0FYlz1jv31kv+vanV1hQX7vmDP9K7ybZP+Dt6wQZ2HFYqtHE4S+SPTkaeBBuiRZFmI/tf4 lWZdJAASwq8UrgAAAAAAAA== --Apple-Mail-30-121285680-- From owner-atom-syntax@mail.imc.org Wed Aug 11 13:57:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22563 for ; Wed, 11 Aug 2004 13:57:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHmKEV069810; Wed, 11 Aug 2004 10:48:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BHmKkd069809; Wed, 11 Aug 2004 10:48:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BHmJIM069781 for ; Wed, 11 Aug 2004 10:48:19 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040811174818.3556.qmail@web41209.mail.yahoo.com> Received: from [67.160.84.159] by web41209.mail.yahoo.com via HTTP; Wed, 11 Aug 2004 10:48:18 PDT Date: Wed, 11 Aug 2004 10:48:18 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateSamRuby +1 To: elias@torrez.us Cc: Norman Walsh , Atom Syntax In-Reply-To: <905f7c91040811102036c66207@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Elias Torres wrote: > > +1 I like it too, but I thought Atom WG was not too > comfortable with > bringing items from DC into the spec? i.e. not using > dc:title and > using atom:title, etc, etc. Extensions are going to exist and the WG should acknowledge that. I think makes a lot of sense to say "all the complex, non-mainstream use cases should be solved in extensions". ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 11 13:58:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22624 for ; Wed, 11 Aug 2004 13:58:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHo6fG069936; Wed, 11 Aug 2004 10:50:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BHo6Jm069935; Wed, 11 Aug 2004 10:50:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BHo6r8069916 for ; Wed, 11 Aug 2004 10:50:06 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040811175003.94591.qmail@web41206.mail.yahoo.com> Received: from [67.160.84.159] by web41206.mail.yahoo.com via HTTP; Wed, 11 Aug 2004 10:50:03 PDT Date: Wed, 11 Aug 2004 10:50:03 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateSamRuby -1 To: Graham , Atom Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Graham wrote: > Differing interpretations of the DC spec as regards > Atom + different > expected behavior + people trying to be clever = my > definition of > interoperability hell (And lots of new convoluted > date code in Shrook > that doesn't actually work all of the time, > presumably) How does your stand of 'include umpteen dates in the spec and then consumers just ignore the ones they don't like' any more of a recipe for interoperability than saying 'here is the core date construct that must be supported and all the funky stuff should be done in optional extensions'? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Wed Aug 11 14:16:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23673 for ; Wed, 11 Aug 2004 14:16:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BI6bsx071982; Wed, 11 Aug 2004 11:06:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BI6bLP071981; Wed, 11 Aug 2004 11:06:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BI6aqA071972 for ; Wed, 11 Aug 2004 11:06:36 -0700 (PDT) (envelope-from eliast@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so253082rnk for ; Wed, 11 Aug 2004 11:06:27 -0700 (PDT) Received: by 10.38.78.1 with SMTP id a1mr2103296rnb; Wed, 11 Aug 2004 11:06:27 -0700 (PDT) Message-ID: <905f7c91040811110657d9be9@mail.gmail.com> Date: Wed, 11 Aug 2004 14:06:26 -0400 From: Elias Torres Reply-To: elias@torrez.us To: Dare Obasanjo Subject: Re: PaceDateSamRuby +1 Cc: elias@torrez.us, Norman Walsh , Atom Syntax In-Reply-To: <20040811174818.3556.qmail@web41209.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Right, I'm fully aware that there will be extensions, but will we state in the spec to use dcterms:* for date or will we simply say atom only has atom:d? Regards, Elias On Wed, 11 Aug 2004 10:48:18 -0700 (PDT), Dare Obasanjo wrote: > > --- Elias Torres wrote: > > > > > +1 I like it too, but I thought Atom WG was not too > > comfortable with > > bringing items from DC into the spec? i.e. not using > > dc:title and > > using atom:title, etc, etc. > > Extensions are going to exist and the WG should > acknowledge that. I think makes a lot of sense to say > "all the complex, non-mainstream use cases should be > solved in extensions". > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 > No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. > > __________________________________ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. > > > http://promotions.yahoo.com/new_mail > From owner-atom-syntax@mail.imc.org Wed Aug 11 14:54:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27202 for ; Wed, 11 Aug 2004 14:54:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIl0Mk075723; Wed, 11 Aug 2004 11:47:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BIl0J1075722; Wed, 11 Aug 2004 11:47:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIl0pL075670 for ; Wed, 11 Aug 2004 11:47:00 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <2004081118465801300175rge>; Wed, 11 Aug 2004 18:46:59 +0000 Date: Wed, 11 Aug 2004 12:46:57 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceDateSamRuby From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 'The "atom:d" element's content conveys a date associated with an event in the life cycle of the entry.' This appears to be quite different from any of the kinds of time stamps we've discussed in the past. It sounds like it's supposed to be an "objective" date, associated with an event--not pulled out of the air or time-shifted by convention like the 2005 model year for cars which begins in the latter half of 2004. But what it objectively identifies is purposely unclear. Does the fact that one can't depend on it to be the time stamp of any PARTICULAR event make the objectivity implied by the spec text useless? Or is the intent simply to eliminate "fanciful" dates, and be satisfied that it's meaning has been narrowed sufficiently? I'm still trying to decide whether that feels satisfying or not. 'Consumers MAY chose to sort based on this value.' ...but we're going to be fairly vague regarding whether it would make sense to do so. 'Consumers MAY chose not to display entries containing atom:d elements until the date specified.' ...but we're not really saying anything about what it means to post date an entry, so who knows whether doing this makes sense or not? Is a posted dated entry not INTENDED for display till it's date comes up (but only as a suggestion--obviously the word is out once the entry is published)? Or is a posted dated entry talking about a future event? There's no way of knowing...for a machine anyway. Some post dating may be a thinly veiled ploy to get one's entries displayed above others' entries (which could be done with any other kind of Date Construct, so that's not a "vulnerability" unique to this proposal). I'm ALMOST satisfied with using dcterms for specific dates. The problems with that are: 1) There's no "subjective" date--at least not in the list in this proposal. 2) There's no "updated" date (vs. "modified"...or is dcterms:modified the date we've been calling "updated"? I could look it up, but either way, one of the two isn't there). The question to me feels like, are we going to be satisfied with something a LITTLE more specific than we've seen in RSS, or do we dare brave the tempestuous waters of hammering out a set of more specific dates? A majority or people who participated in the Date Survey expressed an interest in three particular dates and one non-specific one, two of which aren't available in this proposal. But getting consensus on a proposal that DOES provide each of those looks like it could be difficult. I personally don't see the difficulty in having the four dates many of us expressed interest in. Of course, there are others here who have more experience with this stuff than me. But do any of us have experience with a syndication format that has more than one date construct? If not, then whether that experience bears directly on this issue is at least a valid question. I don't think I'm going to invest any further effort into campaigning for any particular proposal. You have my opinion. From owner-atom-syntax@mail.imc.org Wed Aug 11 14:54:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27236 for ; Wed, 11 Aug 2004 14:54:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIhc2L075425; Wed, 11 Aug 2004 11:43:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BIhc1O075424; Wed, 11 Aug 2004 11:43:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIhc1f075413 for ; Wed, 11 Aug 2004 11:43:38 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id F3F9D7C202; Wed, 11 Aug 2004 21:36:44 +0200 (CEST) Date: Wed, 11 Aug 2004 20:44:59 +0200 To: "Dare Obasanjo" Subject: Re: PaceDateAsbjornUlsberg -1 References: <20040811164646.3465.qmail@web41208.mail.yahoo.com> Cc: Atom-Syntax From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20040811164646.3465.qmail@web41208.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 11 Aug 2004 09:46:46 -0700 (PDT), Dare Obasanjo wrote: > From my perspective as an aggregator developer this seems like > way too many dates and the semantics of some of them confused > me (especially the subtle difference between atom:b & atom:c). atom:b is some sort of «first published» while atom:c is the more vague «published». If we agree that «published» will never change for a given atom:entry, then atom:b can be dropped. > I can't think of which of the dates my application should depend > on. atom:b is really just there because if we don't reach consensus on that the date representing the published date is immutable, I'd still need a date that conveyed the semantics of «first published». If we all agree that atom:c can be immutable, then atom:b can go. > PS: Stylistically I have issues with the fact that the Pace > references [...] which is mainly a guide to all the gotchas > surrounding the DateTime class in the .NET Framework That has nothing to do with the rest of the pace other than it's a good read. > I'm not sure how it is generally relevant to developers at > large that aren't using the .NET Framework. It has some good notes on why it is useful and often necessary to normalize dates to UTC before doing anything with them. My Pace requires time zones on all dates by basing them on RFC 3339 and recommends UTC-normalization of all dates to make them easier to process. If you think this is unecessary, please let me know, and I'll try to rephrase the pace. Since you're -1 on the pace, is there anything else you dislike about it? Isn't it good that it requires at least one date to be present, for example? What could be improved for you to be +1 on it? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 11 14:56:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27469 for ; Wed, 11 Aug 2004 14:56:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIobjt076507; Wed, 11 Aug 2004 11:50:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BIobnu076505; Wed, 11 Aug 2004 11:50:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIoaqO076485 for ; Wed, 11 Aug 2004 11:50:36 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 805817C20A; Wed, 11 Aug 2004 21:43:45 +0200 (CEST) Date: Wed, 11 Aug 2004 20:52:01 +0200 To: "Roger B." Subject: Re: PaceDate* Cc: Atom-Syntax References: <229F51DED35841319E2480A3568F71.MAI@journurl.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <229F51DED35841319E2480A3568F71.MAI@journurl.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 10 Aug 2004 23:56:09 -0500, Roger B. wrote: > PaceDateAsbjornUlsberg: > I don't care for flagging atom:d as a SHOULD NOT. This is now changed. The reason I first wrote SHOULD NOT was because it shouldn't be used as a substitute for any of the other dates. Now, I've added some text explaining if the Date Construct should be human- or tool-provided. atom:d is typically a human-provided date, while all the others are tool-provided. Please let me know what you think. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 11 15:09:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28881 for ; Wed, 11 Aug 2004 15:09:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIxrko077421; Wed, 11 Aug 2004 11:59:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BIxrIq077420; Wed, 11 Aug 2004 11:59:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIxqNu077370 for ; Wed, 11 Aug 2004 11:59:53 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 1D92C7C20A; Wed, 11 Aug 2004 21:53:02 +0200 (CEST) To: "Tim Bray" Cc: Atom-Syntax Subject: Re: PaceDateSamRuby -1 References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> Message-ID: Date: Wed, 11 Aug 2004 21:01:16 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 11 Aug 2004 08:37:17 -0700, Tim Bray wrote: > It respects prior art, provides the minimum necessary to declare victory > and (this is very important), in my opinion based on observing the > discussion to date, it's about the most that we can actually build > consensus around. -1 here. I feel that it just caters for the current practice without doing anything to improve it. I think the current practice needs improvement, which is why I would like more and better specified dates available in the core. Allowing people to use Dublin Core elements does not encourage them to do so. I think we should encourage more shared semantics between tools, which PaceDateSamRuby does not. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 11 15:48:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03577 for ; Wed, 11 Aug 2004 15:48:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJdt9F081629; Wed, 11 Aug 2004 12:39:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BJdtP4081628; Wed, 11 Aug 2004 12:39:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJdsnA081611 for ; Wed, 11 Aug 2004 12:39:55 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7BJdr53004775 for ; Wed, 11 Aug 2004 14:39:53 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i7BJdrw9004771; Wed, 11 Aug 2004 14:39:53 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom Syntax Subject: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> From: Ken MacLeod Date: 11 Aug 2004 14:39:53 -0500 In-Reply-To: <905f7c91040811110657d9be9@mail.gmail.com> Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Elias Torres writes: > Right, I'm fully aware that there will be extensions, but will we > state in the spec to use dcterms:* for date or will we simply say > atom only has atom:d? My reading of PaceDateSamRuby is that Atom 1.0 will only specify, validate, and test interoperability on one date, atom:d. All dct:* dates are optional, and if specified, validated, or tested for interoperability it will be "later" or elsewhere. Two concerns I have with this Pace: 1) Less important: it does not suggest any interoperable means for indicating to a consumer that the entry has changed (at any level of significance, but I'm only concerned about the least significance, such as entity tags, file timestamp, or database change time). The impact of this is that consumers must continue to *always* use client-side hashing on each entry each time they read a feed. This is not critical, as the "change" indicator only tells you when you *don't* have to do hashing (after checking the change indicator, the consumer may/should still do hashing of fields they display to see if they need to signal the user that a change has occurred that is visible to them). 2) More important: it does not suggest any interoperable means for a client to distinguish between two versions of the same entry within a feed (or index or archive). Earlier proposals used a simple, date-based approach for this that allowed core Atom 1.0 interoperability to be achieved while still leaving a "versioning" model to a separate effort. I'm not comfortable with the validation and interoperability testing aspects of the other two Paces (PaceDateAntoneRoundy, PaceDateAsbjornUlsberg), but I also find this Pace critically lacking this simple solution to the above requirements. To provide a concrete example of added spec text, I have created PaceDateKenMacLeod that includes that date. It is otherwise identical to PaceDateSamRuby, so you can skip right to the proposal for the atom:e element. -- Ken From owner-atom-syntax@mail.imc.org Wed Aug 11 16:14:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08107 for ; Wed, 11 Aug 2004 16:14:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJu2dL083077; Wed, 11 Aug 2004 12:56:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BJu2J7083076; Wed, 11 Aug 2004 12:56:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJu09Q083051 for ; Wed, 11 Aug 2004 12:56:01 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 352477C202; Wed, 11 Aug 2004 22:49:11 +0200 (CEST) Date: Wed, 11 Aug 2004 21:57:44 +0200 To: "Sam Ruby" Subject: Re: New AtomPubIssuesList for 2004/08/09 Cc: Atom-Syntax References: <4.2.0.58.J.20040729074056.03971e78@localhost> <41083152.4000507@intertwingly.net> <411798B8.8060702@intertwingly.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <411798B8.8060702@intertwingly.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 09 Aug 2004 11:31:04 -0400, Sam Ruby wrote: > Despite this we seem to have some concerns [4],[5] over the process, so > I am formally including these Paces on today's list. Sounds fine. > Relative to semantics, we have two paces, PaceRecommendIdScheme and > PaceBasicAtomID, both covering similar ground. How (and when) should we proceed with these? > In particular, as WSDL 2.0 is in last call, would the WSDL 2.0 HTTP > bindings be acceptable to all? It is to me, at least. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 11 16:55:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14983 for ; Wed, 11 Aug 2004 16:55:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BKmC6S087778; Wed, 11 Aug 2004 13:48:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BKmCRm087777; Wed, 11 Aug 2004 13:48:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BKmATc087758 for ; Wed, 11 Aug 2004 13:48:11 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 9072F7C122; Wed, 11 Aug 2004 23:41:22 +0200 (CEST) Date: Wed, 11 Aug 2004 22:50:07 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= To: "Ken MacLeod" Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) Cc: Atom-Syntax References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> Message-ID: Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 11 Aug 2004 14:39:53 -0500, Ken MacLeod wrote: > To provide a concrete example of added spec text, I have created > PaceDateKenMacLeod that includes that date. Seeing that there are several widely used publishing tools that doesn't support both of the atom:d and atom:e elements your pace is proposing, I don't think both atom:d and atom:e can be MUST. That's what I like about PaceDateAsbjornUlsberg and PaceDateAntoneRoundy. They only require _one_ date, but they don't specify which one that should be, since current practice is so chaotic that it's impossible to require all tools to support one set of (shared) semantics now. Instead, the specification should hash out the semantics we find useful, and hope that the tools will support and share these eventually. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 11 17:38:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20522 for ; Wed, 11 Aug 2004 17:38:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLRcLI092399; Wed, 11 Aug 2004 14:27:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BLRcqn092398; Wed, 11 Aug 2004 14:27:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-68.dsl.pltn13.pacbell.net [66.125.125.68]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLRbcC092392 for ; Wed, 11 Aug 2004 14:27:37 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Wed, 11 Aug 2004 14:27:39 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: On needs vs. wants Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just another not-so-subtle reminder: we are trying to decide which of the date proposals meet out *needs*, not our *wants*. Some of the recent messages seem to be talking about things that would be nice and/or helpful, not requirements. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 11 17:52:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22278 for ; Wed, 11 Aug 2004 17:52:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLkLJG093798; Wed, 11 Aug 2004 14:46:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BLkLOb093797; Wed, 11 Aug 2004 14:46:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BLkK7u093789 for ; Wed, 11 Aug 2004 14:46:20 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040811214620.47861.qmail@web41202.mail.yahoo.com> Received: from [67.160.84.159] by web41202.mail.yahoo.com via HTTP; Wed, 11 Aug 2004 14:46:20 PDT Date: Wed, 11 Aug 2004 14:46:20 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) To: Ken MacLeod , Atom Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ken MacLeod wrote: > > My reading of PaceDateSamRuby is that Atom 1.0 will > only specify, > validate, and test interoperability on one date, > atom:d. All dct:* > dates are optional, and if specified, validated, or > tested for > interoperability it will be "later" or elsewhere. Same here. > Two concerns I have with this Pace: > > 1) Less important: it does not suggest any > interoperable means for > indicating to a consumer that the entry has > changed (at any level > of significance, but I'm only concerned about > the least > significance, such as entity tags, file > timestamp, or database > change time). > > The impact of this is that consumers must > continue to *always* use > client-side hashing on each entry each time they > read a feed. > This is not critical, as the "change" indicator > only tells you > when you *don't* have to do hashing (after > checking the change > indicator, the consumer may/should still do > hashing of fields they > display to see if they need to signal the user > that a change has > occurred that is visible to them). True, but the client now has to depend on the server's idea of what a change means which may lead to inconsistency when applied to dozens of feeds the average aggregator user might see. To me this is not a big deal but I can imagine that some consumers would rather not have to write the code to keep track of such things themselves. I actually don't in RSS Bandit but instead silently update old content with new content without indicating any change this to the user. > 2) More important: it does not suggest any > interoperable means for a > client to distinguish between two versions of > the same entry > within a feed (or index or archive). Earlier > proposals used a > simple, date-based approach for this that > allowed core Atom 1.0 > interoperability to be achieved while still > leaving a "versioning" > model to a separate effort. Using dates as a versioning mechanism seemed like a hack to me. I definitely oppose all efforts to conflate the date issue with versioning. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 11 18:02:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23685 for ; Wed, 11 Aug 2004 18:02:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLsUeU094359; Wed, 11 Aug 2004 14:54:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BLsUN0094358; Wed, 11 Aug 2004 14:54:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLsTnx094346 for ; Wed, 11 Aug 2004 14:54:30 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7BLsR53006314; Wed, 11 Aug 2004 16:54:28 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i7BLsP13006310; Wed, 11 Aug 2004 16:54:25 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: =?iso-8859-1?q?Asbj=F8rn?= Ulsberg Cc: Atom-Syntax Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> From: Ken MacLeod Date: 11 Aug 2004 16:54:25 -0500 In-Reply-To: Message-ID: Lines: 41 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BLsUnx094353 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg writes: > On 11 Aug 2004 14:39:53 -0500, Ken MacLeod wrote: > > > To provide a concrete example of added spec text, I have created > > PaceDateKenMacLeod that includes that date. > > Seeing that there are several widely used publishing tools that > doesn't support both of the atom:d and atom:e elements your pace is > proposing, I don't think both atom:d and atom:e can be MUST. According to BlogToolDateSurvey, every tool there is capable of providing both atom:d and atom:e in a way that is conformant with the proposed spec, validatable, and testable for interoperability. If the publishing tool does not have a separate value for atom:d, the value for atom:d can be the same value used for atom:e (in PaceDateSamRuby, it would anyway). > That's what I like about PaceDateAsbjornUlsberg and > PaceDateAntoneRoundy. They only require _one_ date, but they don't > specify which one that should be, since current practice is so > chaotic that it's impossible to require all tools to support one set > of (shared) semantics now. > > Instead, the specification should hash out the semantics we find > useful, and hope that the tools will support and share these > eventually. I believe semantics without testable spec assertions to be less useful to implementors. Neither of PaceDateAsbjornUlsberg or PaceDateAntoneRoundy specify interoperable behavior* -- why a producer would include such dates or what consumers will do when they receive them. Both of PaceDateSamRuby and PaceDateKenMacLeod define their dates in the context of what they do in Atom tools, not just what they "mean". -- Ken * excepting some "don't change when you pass-thru" text. From owner-atom-syntax@mail.imc.org Wed Aug 11 18:12:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25245 for ; Wed, 11 Aug 2004 18:12:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BM6R45095200; Wed, 11 Aug 2004 15:06:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BM6RKo095199; Wed, 11 Aug 2004 15:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BM6QVW095190 for ; Wed, 11 Aug 2004 15:06:27 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id ED0557C122; Thu, 12 Aug 2004 00:59:36 +0200 (CEST) To: "Dare Obasanjo" Cc: Atom-Syntax Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) References: <20040811214620.47861.qmail@web41202.mail.yahoo.com> Message-ID: Date: Thu, 12 Aug 2004 00:08:37 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20040811214620.47861.qmail@web41202.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 11 Aug 2004 14:46:20 -0700 (PDT), Dare Obasanjo wrote: > Using dates as a versioning mechanism seemed like a hack to me. > I definitely oppose all efforts to conflate the date issue with > versioning. I second this. As I've written before: the 'updated' date is such a far stretch after a more professional publishing model that I feel that those who want it should stretch all the way, and not just pick the bits they find useful from such a model. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 11 18:26:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26712 for ; Wed, 11 Aug 2004 18:26:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BMInJE096251; Wed, 11 Aug 2004 15:18:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BMInjx096250; Wed, 11 Aug 2004 15:18:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BMIm60096240 for ; Wed, 11 Aug 2004 15:18:49 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id CA3A37C1FB; Thu, 12 Aug 2004 01:11:55 +0200 (CEST) To: "Ken MacLeod" Cc: Atom-Syntax Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> Message-ID: Date: Thu, 12 Aug 2004 00:20:52 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 11 Aug 2004 16:54:25 -0500, Ken MacLeod wrote: > According to BlogToolDateSurvey, every tool there is capable of > providing both atom:d and atom:e in a way that is conformant with the > proposed spec, validatable, and testable for interoperability. The way I understand PaceDateKenMacLeod, atom:d conveys BlogToolDateSurvey's «Creation Date» and atom:e conveys «Changed Date». Unless atom:d also conveys «Display Date», neither Movable Type, WordPress, BigBlogTool, ExpressionEngine nor Blosxom conforms to your pace. If atom:d is both «Creation Date» and «Display Date», your pace should say so explicitly somehow. > If the publishing tool does not have a separate value for atom:d, the > value for atom:d can be the same value used for atom:e (in > PaceDateSamRuby, it would anyway). Which is one reason I don't like PaceDateSamRuby. > I believe semantics without testable spec assertions to be less useful > to implementors. Is it a requirement to be able to have testable spec assertions for something to go into the Atom specification? I have no problem with understanding the usuefulness of it, I just don't see how it can be a requirement. > Neither of PaceDateAsbjornUlsberg or PaceDateAntoneRoundy specify > interoperable behavior* -- why a producer would include such dates or > what consumers will do when they receive them. Good point. I'll try to write something about that. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 11 19:34:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00507 for ; Wed, 11 Aug 2004 19:34:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNOZ2f000469; Wed, 11 Aug 2004 16:24:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BNOZZS000468; Wed, 11 Aug 2004 16:24:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNOYgP000460 for ; Wed, 11 Aug 2004 16:24:34 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc12) with SMTP id <2004081123243401200plqsge>; Wed, 11 Aug 2004 23:24:34 +0000 Date: Wed, 11 Aug 2004 17:24:32 -0600 Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <99D1B954-EBED-11D8-AA08-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, August 11, 2004, at 03:54 PM, Ken MacLeod wrote: > Neither of PaceDateAsbjornUlsberg or PaceDateAntoneRoundy specify > interoperable behavior* -- why a producer would include such dates or > what consumers will do when they receive them. Both of > PaceDateSamRuby and PaceDateKenMacLeod define their dates in the > context of what they do in Atom tools, not just what they "mean". > Why should the behavior be specified or suggested? Isn't that entirely up to the implementor or the user? I don't think we really need to speak on the issue of sort order. Sometimes people will sort by date, sometimes by another criteria. When sorting by date, if we have more than one Date Construct, which to prefer for sorting is an individual preference. As for suggesting that entries MAY not be displayed until a post-dated date is reached, I think that would be an appropriate use for dcterms:available. Unless we explicitly bake that semantic into a core element, it's anybody's guess whether post-dated entries are intended by each publisher to be handled that way. The single atom:d seems to carry some weak ("MAY") SUGGESTIONS for behavior, but doesn't appear to SPECIFY behavior. And the MEANING of the date is not very specific. The only behavior I can think of that might need to be suggested is that the "subjective" date might be thought of as a "display" date. But even that would be nothing more than a weak suggestion--some people may prefer to display one of the objective dates. From owner-atom-syntax@mail.imc.org Wed Aug 11 20:05:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01656 for ; Wed, 11 Aug 2004 20:05:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNufMx002348; Wed, 11 Aug 2004 16:56:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BNufqv002347; Wed, 11 Aug 2004 16:56:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta04-svc.ntlworld.com (mta04-svc.ntlworld.com [62.253.162.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BNueP9002329 for ; Wed, 11 Aug 2004 16:56:41 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from cpc1-stke1-5-0-cust135.bagu.cable.ntl.com ([81.97.134.135]) by mta04-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040811235514.TCND575.mta04-svc.ntlworld.com@cpc1-stke1-5-0-cust135.bagu.cable.ntl.com>; Thu, 12 Aug 2004 00:55:14 +0100 Date: Thu, 12 Aug 2004 00:56:37 +0100 From: David Powell X-Mailer: The Bat! (v2.13 "Lucky" Beta/3) Business Reply-To: David Powell X-Priority: 3 (Normal) Message-ID: <216346686.20040812005637@djpowell.net> To: =?ISO-8859-1?B?QXNiavhybiBVbHNiZXJn?= CC: "Ken MacLeod" , Atom-Syntax Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) In-Reply-To: References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Wednesday, August 11, 2004, 11:20:52 PM, asbjorn@tigerstaden.no wrote: > Good point. I'll try to write something about that. Arghh! - You've renumbered your definitions. That is going to make the discussion very confusing - any chance of changing back to the old numbering system and just missing out atom:c? -- Dave From owner-atom-syntax@mail.imc.org Wed Aug 11 20:25:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02694 for ; Wed, 11 Aug 2004 20:25:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C0G5Ko003844; Wed, 11 Aug 2004 17:16:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C0G5V1003843; Wed, 11 Aug 2004 17:16:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C0G4rp003831 for ; Wed, 11 Aug 2004 17:16:05 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id AFFF07C1FB; Thu, 12 Aug 2004 03:09:14 +0200 (CEST) To: "David Powell" Cc: Atom-Syntax Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> <216346686.20040812005637@djpowell.net> Message-ID: Date: Thu, 12 Aug 2004 02:17:37 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <216346686.20040812005637@djpowell.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 00:56:37 +0100, David Powell wrote: > Arghh! - You've renumbered your definitions. That is going to make the > discussion very confusing - any chance of changing back to the old > numbering system and just missing out atom:c? Of course. Sorry for the confusion I may have caused. atom:c is now simply skipped in the pace, since I think (and hope) atom:b will be able to represent that date. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 11 21:16:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05814 for ; Wed, 11 Aug 2004 21:16:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C15pxl008091; Wed, 11 Aug 2004 18:05:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C15pVd008090; Wed, 11 Aug 2004 18:05:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C15o4Y008084 for ; Wed, 11 Aug 2004 18:05:50 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.17.30.163] (sj-ez-63-96-162-1.bea.com [63.96.162.1]) by mail.mnot.net (Postfix) with ESMTP id 6AA7B727D for ; Wed, 11 Aug 2004 18:05:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceDateSamRuby +1 Date: Wed, 11 Aug 2004 18:05:56 -0700 To: Atom WG X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Seems like the right balance to me. It may be worthwhile to highlight that consumers can (and should) put the decision about what to do with dates into the arms of consumers; e.g., sorting, delayed display, etc. I can imagine future extensions that give much more fine-grained control to feed authors, thus automagically configuring the display and use of dates, but it doesn't look like we're there yet. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Aug 11 21:56:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07974 for ; Wed, 11 Aug 2004 21:56:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C1nZ5T012548; Wed, 11 Aug 2004 18:49:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C1nZIE012547; Wed, 11 Aug 2004 18:49:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C1nVkZ012536; Wed, 11 Aug 2004 18:49:32 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> <216346686.20040812005637@djpowell.net> Date: Wed, 11 Aug 2004 18:49:36 -0700 To: =?iso-8859-1?Q?Asbj=F8rn?= Ulsberg From: Paul Hoffman / IMC Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) Cc: Atom-Syntax Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 2:17 AM +0200 8/12/04, Asbjørn Ulsberg wrote: >Of course. Sorry for the confusion I may have caused. atom:c is now >simply skipped in the pace, since I think (and hope) atom:b will be >able to represent that date. Changing your proposal multiple times in one day does not help the discussion move. Could you instead simply add comments? At this point, the thread about your proposal is badly broken. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 12 03:45:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10625 for ; Thu, 12 Aug 2004 03:45:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C7aNwf086870; Thu, 12 Aug 2004 00:36:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C7aN2D086869; Thu, 12 Aug 2004 00:36:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C7aMAP086836 for ; Thu, 12 Aug 2004 00:36:22 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 0809B7C1FB; Thu, 12 Aug 2004 10:29:18 +0200 (CEST) To: "Mark Nottingham" Cc: Atom-Syntax Subject: Re: PaceDateSamRuby +1 References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> Message-ID: Date: Thu, 12 Aug 2004 09:38:20 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 11 Aug 2004 18:05:56 -0700, Mark Nottingham wrote: > I can imagine future extensions that give much more fine-grained control > to feed authors, thus automagically configuring the display and use of > dates, but it doesn't look like we're there yet. Is it really imaginable that any tool vendor will stretch in any way to use the Dublin Core dates if they aren't encouraged to do so by the specification? Especially when the current practice obviously is considered to work «just fine». -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 05:28:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15794 for ; Thu, 12 Aug 2004 05:28:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C9KNsZ009967; Thu, 12 Aug 2004 02:20:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C9KNZp009966; Thu, 12 Aug 2004 02:20:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C9KMY4009954 for ; Thu, 12 Aug 2004 02:20:22 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 78847 invoked from network); 12 Aug 2004 09:20:19 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 12 Aug 2004 09:20:19 -0000 Received: from 194.203.191.188 ([194.203.191.188]) by webmail.djpowell.net (IMP) with HTTP for ; Thu, 12 Aug 2004 10:20:19 +0100 Message-ID: <1092302419.411b36531cdf5@webmail.djpowell.net> Date: Thu, 12 Aug 2004 10:20:19 +0100 From: David Powell To: =?iso-8859-1?b?QXNiavhybg==?= Ulsberg Cc: Mark Nottingham , Atom-Syntax Subject: Re: PaceDateSamRuby +1 References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 194.203.191.188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Asbjørn Ulsberg : > > On Wed, 11 Aug 2004 18:05:56 -0700, Mark Nottingham wrote: > > > I can imagine future extensions that give much more fine-grained control > > to feed authors, thus automagically configuring the display and use of > > dates, but it doesn't look like we're there yet. > > Is it really imaginable that any tool vendor will stretch in any way to > use the Dublin Core dates if they aren't encouraged to do so by the > specification? Especially when the current practice obviously is > considered to work «just fine». I agree. If the 500+ permathread taught us anything, then I think it is obvious that there is confusion about the meaning of dates and we need to be very clear on how various date terms relate to Atom. I am -1 on PaceDateSamRuby: We need to be explicit on how to apply fine-graned date terms to Atom if they are to have any shared semantics. Yet, I don't believe that Atom should attempt to (re)define how dcterms can be applied to entries. dcterms isn't our namespace, if we provide guidance for its use there is a danger that we may bake a misinterpretation of it into the spec. I think that it is best if we define an explicit set of dates in Atom so that we can clearly specify how they should be applied. Also neither Sam's atom:d or anything in dcterms allows for a subjective date, which was one of the most popular dates in the date survey. Sam's atom:d seems to be a catch-all date for the benefit of pre-Atom systems. We do need to make it easy for RSS users to move to Atom, but this is effectively making a weakly specified legacy field a mandatory element of atom feeds for now and forever more. I am +1 on PaceDateAsbjornUlsberg: Both PaceDateSamRuby and PaceDateAsbjornUlsberg require a single mandatory date. The difference is, PaceDateAsbjornUlsberg provides the metadata to enable the publisher to say what that date means. I'm far more comfortable with this than saying: "Here is atom:d, it might mean created, modified, or issued - I can't tell you and you can't guess". -- Dave From owner-atom-syntax@mail.imc.org Thu Aug 12 05:29:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15842 for ; Thu, 12 Aug 2004 05:29:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C9GBT3009153; Thu, 12 Aug 2004 02:16:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C9GBYZ009152; Thu, 12 Aug 2004 02:16:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C9GABO009118 for ; Thu, 12 Aug 2004 02:16:10 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id DC5137C1FB; Thu, 12 Aug 2004 12:09:10 +0200 (CEST) Date: Thu, 12 Aug 2004 11:17:20 +0200 To: "Dare Obasanjo" Subject: Re: PaceDateSamRuby +1 Cc: Atom-Syntax References: <20040812085425.68482.qmail@web41202.mail.yahoo.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20040812085425.68482.qmail@web41202.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 01:54:25 -0700 (PDT), Dare Obasanjo wrote: > If extensions provide value and users want the > functionality then vendors will support the features. If you say so. > It seems you are trying to force edge cases that you know > won't get mainstream support into the core of Atom. First, I'm not forcing anything. My pace only requires _one_ date to be present. Which one is totally up to the producer. Secondly, the Dublin Core dates are not edge cases. Most professional publishing services have these dates already. > I'd rather that the core contained what was absolutely > necessary Absolutely necessary for whom? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 06:55:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21602 for ; Thu, 12 Aug 2004 06:55:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CAjBht031195; Thu, 12 Aug 2004 03:45:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CAjBnS031194; Thu, 12 Aug 2004 03:45:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7CAjADq031147 for ; Thu, 12 Aug 2004 03:45:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 38753 messnum 15253013 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 12 Aug 2004 10:45:06 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail11.svc.cra.dublin.eircom.net (qp 38753) with SMTP; 12 Aug 2004 10:45:06 -0000 Message-ID: <411B4A28.5080709@dehora.net> Date: Thu, 12 Aug 2004 11:44:56 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom-Syntax Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> <216346686.20040812005637@djpowell.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Paul Hoffman / IMC wrote: > > At 2:17 AM +0200 8/12/04, Asbjørn Ulsberg wrote: > >> Of course. Sorry for the confusion I may have caused. atom:c is now >> simply skipped in the pace, since I think (and hope) atom:b will be >> able to represent that date. > > > Changing your proposal multiple times in one day does not help the > discussion move. Could you instead simply add comments? At this point, > the thread about your proposal is badly broken. Can I echo that sentiment, and also for thread headings that have +1 in them - bad idea that. There are people responding to "* +1" postings with 0 and -1 sentiments. I for one can't make head nor tail of people's position or where consensus is leaning if anywhere. I would suggest starting over with more sensibly titled threads. cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 12 10:50:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06509 for ; Thu, 12 Aug 2004 10:50:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEeGtT085968; Thu, 12 Aug 2004 07:40:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CEeGQl085967; Thu, 12 Aug 2004 07:40:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEeFqh085931 for ; Thu, 12 Aug 2004 07:40:15 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7CEeA53018102 for ; Thu, 12 Aug 2004 09:40:10 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i7CEe9Ko018098; Thu, 12 Aug 2004 09:40:09 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom-Syntax Subject: testing the spec and interoperability References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> From: Ken MacLeod Date: 12 Aug 2004 09:40:09 -0500 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7CEeFqh085959 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg writes: > Is it a requirement to be able to have testable spec assertions for > something to go into the Atom specification? I have no problem with > understanding the usuefulness of it, I just don't see how it can be > a requirement. Yes, I do feel strongly that any feature in the core whose use is not implemented by at least two implementations (depending on role: publisher, reader, intermediary) should be struck from the spec. That's the second half of "rough concensus, and running code". The simplest way to check to see if a feature is implemented is to have a checklist drawn from the spec's stated assertions or directly derived from them, and then run through each implementation and see if it adheres to the spec. Just as importantly, you then have to pair-up implementations to see if they are consistent with each other, in case we missed something in the checklist. This works both ways: by testing implementations against the spec we are also testing the spec against the implementations. -- Ken From owner-atom-syntax@mail.imc.org Thu Aug 12 11:14:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08349 for ; Thu, 12 Aug 2004 11:14:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEwUh1089882; Thu, 12 Aug 2004 07:58:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CEwU3Z089881; Thu, 12 Aug 2004 07:58:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CEwSfC089859 for ; Thu, 12 Aug 2004 07:58:29 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 13 Aug 2004 01:04:22 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 Aug 2004 00:57:52 +1000 Subject: Re: PaceDateSamRuby -1 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1092302419.411b36531cdf5@webmail.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: Content-Transfer-Encoding: 7bit On 12/8/04 7:20 PM, "David Powell" wrote: > We need to be explicit on how to apply fine-grained date terms to Atom if they > are to have any shared semantics. Yet, I don't believe that Atom should > attempt to (re)define how dcterms can be applied to entries. dcterms isn't > our namespace, if we provide guidance for its use there is a danger that we > may bake a misinterpretation of it into the spec. > > I think that it is best if we define an explicit set of dates in Atom so that > we can clearly specify how they should be applied. > +1 From owner-atom-syntax@mail.imc.org Thu Aug 12 13:04:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15669 for ; Thu, 12 Aug 2004 13:04:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CGnoBd000911; Thu, 12 Aug 2004 09:49:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CGnoj3000910; Thu, 12 Aug 2004 09:49:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CGnooX000902 for ; Thu, 12 Aug 2004 09:49:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7CGnrfO015895; Thu, 12 Aug 2004 09:49:53 -0700 (PDT) Received: from [192.168.241.188] ([216.125.144.129]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i7CGnqQ4003222; Thu, 12 Aug 2004 09:49:52 -0700 (PDT) In-Reply-To: <20040811175003.94591.qmail@web41206.mail.yahoo.com> References: <20040811175003.94591.qmail@web41206.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-41-139009909; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceDateSamRuby -1 Date: Wed, 11 Aug 2004 17:20:42 -0500 To: Dare Obasanjo X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-41-139009909 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 11 Aug 2004, at 12:50 pm, Dare Obasanjo wrote: > How does your stand of 'include umpteen dates in the > spec and then consumers just ignore the ones they > don't like' any more of a recipe for interoperability > than saying 'here is the core date construct that must > be supported and all the funky stuff should be done in > optional extensions'? Because in the latter the DC dates aren't extensions. PaceDateSamRuby essentially introduces all of the DC dates into the core without bothering to properly define their usage because, in name[space] only, they're extensions. I don't want to deal with 12 ill-defined date fields. Whereas a small number of core elements, with definitions properly defined as they relate to the processes of syndication, is totally manageable. And if people do stuff outside of the core, it's okay for me to ignore them. PaceDateSamRuby exists purely because of the perceived difficulties we've had with the AtomPub process - it is not a good technical solution. Graham --Apple-Mail-41-139009909 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODExMjIyMDQzWjAjBgkqhkiG9w0BCQQxFgQUOgZLEuotkdvssPK7bqniXMCm b1UweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAqSxgYEcweL5MRtxpiJpFynED u4QS6+MoUApgrkrWfR5dji4YJ6NwCikAYGDQKWgB+rvKiga0OT4RjAxGCaUdwwvF2f2uwOD8sBMf xVU2fBNsf1ar0XDrs0rzDimhFCVU41S0HYl3K3+RhlLO8wXVlJdhul0wBtdENxNmesNrrgDXQegx msJAbU30Mr5FGpydbs31Tnhyv+LHA/aofNBEV/RjmJ+rg/Rgbqdug1nWvSX+YCewYT5FAG+mr/Ym ir++pF7W1CHCu4zhP7hc45vlHFE05nuTb3rlzJhD9AKnJyuXcIXwqDoQgO5qzoXfmtwupcmdsYz0 m21oRQAhz3IPvgAAAAAAAA== --Apple-Mail-41-139009909-- From owner-atom-syntax@mail.imc.org Thu Aug 12 13:23:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16987 for ; Thu, 12 Aug 2004 13:23:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CH9qJi003301; Thu, 12 Aug 2004 10:09:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CH9qPQ003300; Thu, 12 Aug 2004 10:09:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41201.mail.yahoo.com (web41201.mail.yahoo.com [66.218.93.34]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7CH9qXA003290 for ; Thu, 12 Aug 2004 10:09:52 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040812170948.53680.qmail@web41201.mail.yahoo.com> Received: from [24.18.132.187] by web41201.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 10:09:48 PDT Date: Thu, 12 Aug 2004 10:09:48 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateSamRuby -1 To: Graham Cc: Atom Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Graham wrote: > On 11 Aug 2004, at 12:50 pm, Dare Obasanjo wrote: > > > How does your stand of 'include umpteen dates in > the > > spec and then consumers just ignore the ones they > > don't like' any more of a recipe for > interoperability > > than saying 'here is the core date construct that > must > > be supported and all the funky stuff should be > done in > > optional extensions'? > > Because in the latter the DC dates aren't > extensions. PaceDateSamRuby > essentially introduces all of the DC dates into the > core without > bothering to properly define their usage because, in > name[space] only, > they're extensions. I don't want to deal with 12 > ill-defined date > fields. Interesting. I assume you haven't read their spec then. Looking at http://web.resource.org/rss/1.0/modules/dcterms/ I don't see how they are any worse defined than any of the proposals on the Atom list. In fact, I have found them less ambiguous and prone to misinterpretation than the dates I saw proposed in the two other Paces I read yesterday. > Whereas a small number of core elements, with > definitions properly > defined as they relate to the processes of > syndication, is totally > manageable. And if people do stuff outside of the > core, it's okay for > me to ignore them. Fine, show me the proposal that hits this 80/20 point yet is unambiguous and clear. Neither of the other 2 Paces struck me as being properly defined or straightforward for producers or consumers to understand. > PaceDateSamRuby exists purely because of the > perceived difficulties > we've had with the AtomPub process - it is not a > good technical > solution. The elements in the dcterms namespace look like an excellent technical solution to myriad arguments I've seen on this list around dates. Please read the spec. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 12 13:36:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18171 for ; Thu, 12 Aug 2004 13:36:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHPBBl004410; Thu, 12 Aug 2004 10:25:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CHPB7M004409; Thu, 12 Aug 2004 10:25:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHPATH004387 for ; Thu, 12 Aug 2004 10:25:11 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7CHP653019884 for ; Thu, 12 Aug 2004 12:25:06 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i7CHP654019880; Thu, 12 Aug 2004 12:25:06 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom-Syntax Subject: Re: PaceDateSamRuby +1 References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> <1092302419.411b36531cdf5@webmail.djpowell.net> From: Ken MacLeod Date: 12 Aug 2004 12:25:06 -0500 In-Reply-To: <1092302419.411b36531cdf5@webmail.djpowell.net> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Powell writes: > I agree. If the 500+ permathread taught us anything, then I think > it is obvious that there is confusion about the meaning of dates and > we need to be very clear on how various date terms relate to Atom. > > I am -1 on PaceDateSamRuby: > > We need to be explicit on how to apply fine-graned date terms to > Atom if they are to have any shared semantics. Yet, I don't believe > that Atom should attempt to (re)define how dcterms can be applied to > entries. dcterms isn't our namespace, if we provide guidance for > its use there is a danger that we may bake a misinterpretation of it > into the spec. > > I think that it is best if we define an explicit set of dates in > Atom so that we can clearly specify how they should be applied. Could you take your preferred date Pace and, assuming it is adopted and properly implemented by clients, say what checks someone would perform to test clients for conformance? That's my biggest stumbling block, I'm not seeing how some of the "fine grained" date proposals are supposed to be applied. -- Ken From owner-atom-syntax@mail.imc.org Thu Aug 12 13:43:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18650 for ; Thu, 12 Aug 2004 13:43:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHaoUk005342; Thu, 12 Aug 2004 10:36:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CHao9x005341; Thu, 12 Aug 2004 10:36:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHan4W005334 for ; Thu, 12 Aug 2004 10:36:49 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7CHaqro006334; Thu, 12 Aug 2004 10:36:53 -0700 (PDT) Received: from [192.168.241.188] ([216.125.144.129]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i7CHaeQ4019423; Thu, 12 Aug 2004 10:36:44 -0700 (PDT) In-Reply-To: <20040812170948.53680.qmail@web41201.mail.yahoo.com> References: <20040812170948.53680.qmail@web41201.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-45-208388831; protocol="application/pkcs7-signature" Message-Id: <38445FBE-EC86-11D8-B7AB-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceDateSamRuby -1 Date: Thu, 12 Aug 2004 12:37:01 -0500 To: Dare Obasanjo X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-45-208388831 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 12 Aug 2004, at 12:09 pm, Dare Obasanjo wrote: > Interesting. I assume you haven't read their spec then. Looking at > http://web.resource.org/rss/1.0/modules/dcterms/ I don't see how they > are any worse defined than any of the proposals on the Atom list. In > fact, I have found them less ambiguous and prone to misinterpretation > than the dates I saw proposed in the two other Paces I read yesterday. You're right, I haven't looked at it in a while, but I remember it being thin. I don't see anything much about revisions to documents, which is the big thing that separates syndication from, say, email. The process those dates are built around isn't one where the document appears to change ever. And the other thing, I can only guess at how publishers might use those dates and fields in their feeds - there's no way I could implement anything straight from the spec, which I could with some of the other proposals. > Fine, show me the proposal that hits this 80/20 point > yet is unambiguous and clear. Neither of the other 2 > Paces struck me as being properly defined or > straightforward for producers or consumers to > understand. PaceEntryDates still looks good (though as I've said before, the wording about entries being issued again isn't quite right yet). Graham --Apple-Mail-45-208388831 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODEyMTczNzAyWjAjBgkqhkiG9w0BCQQxFgQUqbTDrRkzJst48kUX0WJaXBRZ D1gweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAhv1NTo+jUt02MgbYyOQXk0kS UqxA+mNVnleU0VGpiETM5/xzuumo7+Be2yWFyo6WQSsXfq1az3UQ/L/O7tmS9lJcl01MTIrGvRet TukhpkoDbbwwHjifaV5cLpn1lkWOwqTmZc3vrn++n8/gA0Jpecp0WQ5yN7zudk+ee4A1Lre6p2FX 3CxSrrJjWhZRpKGUUlGztIczyiZ+eCRJFO1HXhT8Ps2zEaSlNQfuA2hzZi5LJbmL55lZu/hwHyZ/ 3gzCo/FbqoIT2WEVqlkIgLRf5j1BiMzcsrl61SvPibAxvylvrFqUC4oRJ5SX4/E3uaJE8pd85pSb 2TMOjsXdHXXQigAAAAAAAA== --Apple-Mail-45-208388831-- From owner-atom-syntax@mail.imc.org Thu Aug 12 13:52:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19060 for ; Thu, 12 Aug 2004 13:52:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHj86o006077; Thu, 12 Aug 2004 10:45:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CHj8IU006076; Thu, 12 Aug 2004 10:45:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CHj8wO006070 for ; Thu, 12 Aug 2004 10:45:08 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7CHj81W016376; Thu, 12 Aug 2004 10:45:10 -0700 (PDT) Received: from [192.168.241.188] ([216.125.144.129]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i7CHj0BA024048; Thu, 12 Aug 2004 10:45:03 -0700 (PDT) In-Reply-To: References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> <1092302419.411b36531cdf5@webmail.djpowell.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-46-208888870; protocol="application/pkcs7-signature" Message-Id: <62507904-EC87-11D8-B7AB-000A95DC3D90@mac.com> Cc: Atom-Syntax From: Graham Subject: Re: PaceDateSamRuby +1 Date: Thu, 12 Aug 2004 12:45:21 -0500 To: Ken MacLeod X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-46-208888870 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 12 Aug 2004, at 12:25 pm, Ken MacLeod wrote: > Could you take your preferred date Pace and, assuming it is adopted > and properly implemented by clients, say what checks someone would > perform to test clients for conformance? Surely you just use the program and see if it's displaying nonsense? You don't always need formal tests, do you? Graham --Apple-Mail-46-208888870 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODEyMTc0NTIyWjAjBgkqhkiG9w0BCQQxFgQUtEiC6zFSwWQvf+Xbq5MGZdiR im4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEABag2pvkk2faPhD2986MIRQtZ kggar0TCVc4xt4KqfVVMkw3yMizNSJiXYRUbx2xNyuNFWAKsXErlzk/dCvRRy+RsruVguiiGAM+w DnAthwMtkwi1j5C4gou+g46EQEjMxaGSAgqLc3ST9PysUaBa57WwWBhRdmb2yfCGiQW3T2SmmgF6 oeiMSrFmSt6SZFxuDFdRv6crHf6difIemiH4OgB9p/jW+5RONDk4EBV+C3SdW+JoW6QfZcbQR6Jy KjFtBakmihhPxbdVJPnv4NzzDiIAa49RDtlU3ZoJ/7gbMHRIo09Uv57eX+Lb+Dh62Qix9W9nOhU9 Q8JnAgszY1FsAQAAAAAAAA== --Apple-Mail-46-208888870-- From owner-atom-syntax@mail.imc.org Thu Aug 12 14:17:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20455 for ; Thu, 12 Aug 2004 14:17:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CI7jEM008203; Thu, 12 Aug 2004 11:07:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CI7j6L008202; Thu, 12 Aug 2004 11:07:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7CI7jId008191 for ; Thu, 12 Aug 2004 11:07:45 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040812180744.94101.qmail@web41210.mail.yahoo.com> Received: from [207.46.238.143] by web41210.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 11:07:44 PDT Date: Thu, 12 Aug 2004 11:07:44 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateSamRuby -1 To: Graham Cc: Atom Syntax In-Reply-To: <38445FBE-EC86-11D8-B7AB-000A95DC3D90@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Graham wrote: > > > You're right, I haven't looked at it in a while, but > I remember it > being thin. I don't see anything much about > revisions to documents, > which is the big thing that separates syndication > from, say, email. The > process those dates are built around isn't one where > the document > appears to change ever. Again, I'd suggest rereading the spec. There are several elements on revisions to documents such as dcterms:isVersionOf, dcterms:replaces and dcterms:isReplacedBy which are explicit mechanisms for revisioning documents as opposed to the numerous hacks proposed on this list for overloading the semantics of dates. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 12 14:21:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20686 for ; Thu, 12 Aug 2004 14:21:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CIBUeH008483; Thu, 12 Aug 2004 11:11:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CIBUdx008482; Thu, 12 Aug 2004 11:11:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7CIBTMR008469 for ; Thu, 12 Aug 2004 11:11:29 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040812181128.94938.qmail@web41210.mail.yahoo.com> Received: from [131.107.76.143] by web41210.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 11:11:28 PDT Date: Thu, 12 Aug 2004 11:11:28 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateSamRuby +1 To: Graham , Ken MacLeod Cc: Atom-Syntax In-Reply-To: <62507904-EC87-11D8-B7AB-000A95DC3D90@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Graham wrote: > On 12 Aug 2004, at 12:25 pm, Ken MacLeod wrote: > > > Could you take your preferred date Pace and, > assuming it is adopted > > and properly implemented by clients, say what > checks someone would > > perform to test clients for conformance? > > Surely you just use the program and see if it's > displaying nonsense? > You don't always need formal tests, do you? What does displaying nonsense mean? If someone sends me a bug report saying a feed does X in Shrook while RSS Bandit does Y how do we know which behavior is correct? For example, in NetNewsWire if the pubDate is changed in the feed the item's display date in the application is changed while this is not the case in RSS Bandit. Which behavior is correct and why? These are the kinds of questions a spec is supposed to answer. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 12 15:29:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25845 for ; Thu, 12 Aug 2004 15:29:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJFl1e017099; Thu, 12 Aug 2004 12:15:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJFlg6017098; Thu, 12 Aug 2004 12:15:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJFjfP017065; Thu, 12 Aug 2004 12:15:46 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 5C00B7C122; Thu, 12 Aug 2004 22:08:38 +0200 (CEST) Date: Thu, 12 Aug 2004 21:17:01 +0200 To: "Paul Hoffman / IMC" Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) Cc: Atom-Syntax References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> <216346686.20040812005637@djpowell.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 11 Aug 2004 18:49:36 -0700, Paul Hoffman / IMC wrote: > Changing your proposal multiple times in one day does not help the > discussion move. Could you instead simply add comments? At this point, > the thread about your proposal is badly broken. Not really, imho, since no one afaik have commented on the (big) changes I've made lately. Thus, I've reverted the page to the one that has been discussed, and rather created a new page that reflects my new view proposal. I hope this is okay. The new page is: The difference between PaceDateAsbjornUlsberg and PaceDateAsbjornUlsberg2 is that PaceDateAsbjornUlsberg2 don't have atom:c and that it contains text to say what publishers and consumers may do with the dates (not sure how useful this is, though). -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 15:33:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26059 for ; Thu, 12 Aug 2004 15:33:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJGMkr017137; Thu, 12 Aug 2004 12:16:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CJGME6017136; Thu, 12 Aug 2004 12:16:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJGLjc017127 for ; Thu, 12 Aug 2004 12:16:22 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 16AA67C122; Thu, 12 Aug 2004 22:09:22 +0200 (CEST) To: =?iso-8859-1?Q?Bill_de_h=D3ra?= Cc: Atom-Syntax Subject: Re: PaceDateKenMacLeod (was Re: PaceDateSamRuby +1) References: <20040811174818.3556.qmail@web41209.mail.yahoo.com> <905f7c91040811110657d9be9@mail.gmail.com> <216346686.20040812005637@djpowell.net> <411B4A28.5080709@dehora.net> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 12 Aug 2004 21:17:40 +0200 In-Reply-To: <411B4A28.5080709@dehora.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 11:44:56 +0100, Bill de hÓra wrote: > I would suggest starting over with more sensibly titled threads. I can only say +1 to that. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 16:17:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01705 for ; Thu, 12 Aug 2004 16:17:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CK3YRe022425; Thu, 12 Aug 2004 13:03:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CK3Ytx022424; Thu, 12 Aug 2004 13:03:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CK3XKt022418 for ; Thu, 12 Aug 2004 13:03:33 -0700 (PDT) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BvLnV-0001pM-00 for atom-syntax@imc.org; Thu, 12 Aug 2004 22:03:37 +0200 Received: from [217.247.95.133] (helo=baron) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BvLnU-0002VD-00 for atom-syntax@imc.org; Thu, 12 Aug 2004 22:03:37 +0200 Message-ID: <000001c480a7$9be534c0$855ff7d9@baron> From: "Andreas Sewe" To: "[Atom]" Date: Thu, 12 Aug 2004 19:10:59 +0200 Organization: Fachbereich Informatik, TU Darmstadt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:275eb74a6eb9feb006a62452721ee94c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > In your comments on them, please state what style hat you are wearing > (client developer, content aggregator, publisher, and so on) and > which you think best fits your needs. It is OK to talk about your > wants as well, but please focus on needs, given that this is for the > Atom *core* document. On top of my lurker's hat I am wearing a publisher's one. Out of the original proposals I liked PaceDateSamRuby [1] best, but now there is PaceDateKenMacLeod [2] as well which I like even better. And here's why: Personally I would rather see the dcterms used as an extension instead of being redefined in the atom namespace. So, +1 on PaceDateKenMacLeod, +0.5 on PaceDateSamRuby. Regards, Andreas Sewe [1] [2] From owner-atom-syntax@mail.imc.org Thu Aug 12 17:12:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08264 for ; Thu, 12 Aug 2004 17:12:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CKterd028292; Thu, 12 Aug 2004 13:55:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CKte0S028291; Thu, 12 Aug 2004 13:55:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CKtcJf028268 for ; Thu, 12 Aug 2004 13:55:39 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id B22687C1EE; Thu, 12 Aug 2004 23:48:36 +0200 (CEST) Date: Thu, 12 Aug 2004 22:57:18 +0200 To: "Ken MacLeod" Subject: Re: PaceDateSamRuby +1 Cc: Atom-Syntax References: <53A79E1A-EBAC-11D8-BC85-000A95A51C9E@sun.com> <1092302419.411b36531cdf5@webmail.djpowell.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 12 Aug 2004 12:25:06 -0500, Ken MacLeod wrote: > Could you take your preferred date Pace and, assuming it is adopted > and properly implemented by clients, say what checks someone would > perform to test clients for conformance? How is it easier to test conformance with either PaceDateKenMacLeod or PaceDateSamRuby than the others? > That's my biggest stumbling block, I'm not seeing how some of the > "fine grained" date proposals are supposed to be applied. I'm not seeing how it is possible to test any date proposal at all. You can check the date's syntax, you can check if it's a future or present date, you can check if it has a local timezone and you can compare one date with the other (if there's multiple dates). Much more than that would be impossible regardless of what the specification says and the number of date elements we have, no? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 17:22:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09001 for ; Thu, 12 Aug 2004 17:22:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CL8Dil029693; Thu, 12 Aug 2004 14:08:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CL8DuF029692; Thu, 12 Aug 2004 14:08:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CL8CdQ029668 for ; Thu, 12 Aug 2004 14:08:12 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 107137C1EE; Fri, 13 Aug 2004 00:01:11 +0200 (CEST) Date: Thu, 12 Aug 2004 23:09:54 +0200 To: "Dare Obasanjo" Subject: Re: PaceDateSamRuby +1 Cc: Atom-Syntax References: <20040812181128.94938.qmail@web41210.mail.yahoo.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20040812181128.94938.qmail@web41210.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 11:11:28 -0700 (PDT), Dare Obasanjo wrote: > For example, in NetNewsWire if the pubDate is changed in the feed the > item's display date in the application is changed while this is not > the case in RSS Bandit. Which behavior is correct and why? These > are the kinds of questions a spec is supposed to answer. Then please help us answer them. I can't see how either PaceDateKenMacLeod or PaceDateSamRuby specifies this any better than the other paces. They both state what the consumer MAY do with the date(s), but I can't see how that improves interoperability or consistency between clients. In PaceDateAsbjornUlsberg2, I've added some text covering this as well. To improve consistency between clients, we need to say what the dates specifically should represent. Is it e.g. possible to agree on what date should be the «sort date»? I think not, since what the client sorts on most likely is modifyable by the user. Is it possible to agree on what date should work as the «display date»? Perhaps. But won't the date available be displayed, no matter what that is? If a Pace with multiple dates is chosen, which dates have precedence over the others? Is the subjective date more preferrable as a display date than the date of formal issuance? Questions like these needs to be answered. They are not answered in any date paces yet. As I don't use any common RSS aggregators, I'm not the right man to answer these questions. I really don't care what aggregators do with the dates. The can convert them to linux timestamp, add them all together and divide them by pi for all I care. What I care about is what the publishers do with the dates, which is why I have used so many words in my pace(s) to explain how publishers should treat each date element. If there's still not enough text in my pace(s) about how publishers should treat the date elements, please let me know what's missing. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 17:39:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10031 for ; Thu, 12 Aug 2004 17:39:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CLW4L7033031; Thu, 12 Aug 2004 14:32:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CLW4r5033030; Thu, 12 Aug 2004 14:32:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7CLW3Lg033012 for ; Thu, 12 Aug 2004 14:32:03 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040812213201.52881.qmail@web41213.mail.yahoo.com> Received: from [207.46.238.133] by web41213.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 14:32:01 PDT Date: Thu, 12 Aug 2004 14:32:01 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateSamRuby +1 To: "Asbjørn_Ulsberg" Cc: Atom-Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Asbjørn_Ulsberg wrote: > On Thu, 12 Aug 2004 11:11:28 -0700 (PDT), Dare > Obasanjo > wrote: > > > For example, in NetNewsWire if the pubDate is > changed in the feed the > > item's display date in the application is changed > while this is not > > the case in RSS Bandit. Which behavior is correct > and why? These > > are the kinds of questions a spec is supposed to > answer. > > Then please help us answer them. I can't see how > either PaceDateKenMacLeod > or PaceDateSamRuby specifies this any better than > the other paces. They > both state what the consumer MAY do with the > date(s), but I can't see how > that improves interoperability or consistency > between clients. In > PaceDateAsbjornUlsberg2, I've added some text > covering this as well. There's only one date in PaceSamRuby. I don't see how any ambiguity or interoperability issues can arrive from misinterpreting a single date. The one ambiguity from previous experience in RSS is resolved because it is explicitly stated that the value of the date field can change. > To improve consistency between clients, we need to > say what the dates > specifically should represent. Is it e.g. possible > to agree on what date > should be the «sort date»? I think not, since what > the client sorts on > most likely is modifyable by the user. > Is it possible to agree on what date should work as > the «display date»? > Perhaps. But won't the date available be displayed, > no matter what that > is? If a Pace with multiple dates is chosen, which > dates have precedence > over the others? Is the subjective date more > preferrable as a display date > than the date of formal issuance? > It is silly for the spec to try to dictate which dates clients should display to users or use for sorting. You can spec it if you want, I'll ignore it in my application and do what I think is best for my users based on their feedback. By the way none of these problems exist if we just adopt PaceSamRuby. > Questions like these needs to be answered. They are > not answered in any > date paces yet. As I don't use any common RSS > aggregators, I'm not the > right man to answer these questions. I really don't > care what aggregators > do with the dates. The can convert them to linux > timestamp, add them all > together and divide them by pi for all I care. So why are you holding up consensus by ratholing on these points then? > What I care about is what the publishers do with the > dates, which is why I > have used so many words in my pace(s) to explain how > publishers should > treat each date element. If there's still not enough > text in my pace(s) > about how publishers should treat the date elements, > please let me know > what's missing. What is so wrong with using the existing and very clearly defined dates in http://purl.org/rss/1.0/modules/dcterms/ They cover the dates in the significant publishing scenarios as well as define mechanisms for versioning and superceding. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 12 17:45:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10460 for ; Thu, 12 Aug 2004 17:45:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CLd8BC033625; Thu, 12 Aug 2004 14:39:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CLd8Ij033624; Thu, 12 Aug 2004 14:39:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CLd7C9033612 for ; Thu, 12 Aug 2004 14:39:08 -0700 (PDT) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BvNHy-0000Ru-00 for atom-syntax@imc.org; Thu, 12 Aug 2004 23:39:10 +0200 Received: from [217.247.87.23] (helo=baron) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BvNHx-0005j3-00 for atom-syntax@imc.org; Thu, 12 Aug 2004 23:39:09 +0200 Message-ID: <000c01c480b4$f52c3440$1757f7d9@baron> From: "Andreas Sewe" To: "[Atom]" Subject: On PaceDateSamRuby and PaceDateKenMacLeod Date: Thu, 12 Aug 2004 23:40:07 +0200 Organization: Fachbereich Informatik, TU Darmstadt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:275eb74a6eb9feb006a62452721ee94c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry, I accidentally hit the send button. Please ignore my previous posting. There I wrote, rather incompletely: > Paul Hoffman wrote: > > In your comments on them, please state what style hat you are wearing > > (client developer, content aggregator, publisher, and so on) and > > which you think best fits your needs. It is OK to talk about your > > wants as well, but please focus on needs, given that this is for the > > Atom *core* document. > On top of my lurker's hat I am wearing a publisher's one. Out of the > original proposals I liked PaceDateSamRuby [1] best, but now there is > PaceDateKenMacLeod [2] as well which I like even better. And here's why: > Personally I would rather see the dcterms used as an extension instead of > being redefined in the atom namespace. Especially PaceDateSamRuby with its single date, which, if I understood the intended purpose of atom:d correctly, is aimed mostly at the presentation of entries to the user. But then again I might have read too much into "Consumers MAY chose to sort based on this value". To this user-agent centric date the dcterm dates are mostly orthogonal as they reflect the publishing process more than the user/presentation aspect. At any rate, this orthogonality is IMHO a good thing, whereas PaceDateAntoneRoundy and PaceDateAsbjornUlsberg both define a number of dates very similar to those defined by dcterms while not including other dates also defined by dcterms. Why preferring one subset of dcterm dates over another? Now PaceDateKenMacLeod too includes a date which is defined similarily in dcterms: atom:e (which, at least to me, looks similar to dcterms:modified). It has additional implicitions though, because it is meant as some kind of entry versioning mechanism: "Publishers may provide more than one instance or version of the same atom:entry within the same atom:feed (ie. with equivalent atom:id values), consumers MAY choose to only record, process, or present the atom:entry with the latest atom:e value." I'm not sure I like this. IMHO a real supersedes mechanism would be better. > So, +1 on PaceDateKenMacLeod, +0.5 on PaceDateSamRuby. So please allow me to changes this to +1 on PaceDateSamRuby only, taking my concerns about entry versioning disguised as atom:e into account. Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Thu Aug 12 18:13:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12553 for ; Thu, 12 Aug 2004 18:13:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CM33DQ036142; Thu, 12 Aug 2004 15:03:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CM332B036141; Thu, 12 Aug 2004 15:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CM32Uc036135 for ; Thu, 12 Aug 2004 15:03:02 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Thu, 12 Aug 2004 15:03:05 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Please use better Subject thread names Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ahem. This is kind of obvious, no? Even a few of you who agreed with a previous poster who suggested it have continued to use useless thread titles. At this point, the discussion cannot be followed by typical WG participants. That is a Very Bad Thing. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 12 18:37:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14142 for ; Thu, 12 Aug 2004 18:37:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMLrdX038652; Thu, 12 Aug 2004 15:21:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CMLrED038651; Thu, 12 Aug 2004 15:21:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMLqEd038642 for ; Thu, 12 Aug 2004 15:21:52 -0700 (PDT) (envelope-from grayrest@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so306748rnk for ; Thu, 12 Aug 2004 15:21:50 -0700 (PDT) Received: by 10.38.78.1 with SMTP id a1mr2643526rnb; Thu, 12 Aug 2004 15:21:50 -0700 (PDT) Message-ID: <476b71e80408121521644a6550@mail.gmail.com> Date: Thu, 12 Aug 2004 18:21:50 -0400 From: grayrest To: atom-syntax@imc.org Subject: paceDateKarlGuertin Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi all. I've thrown my own proposal [1] on the fire. I prefer the two fuller date proposals (Asbjorn, Antone) over the other two (Sam's and Ken's) and Ken's over Sam's. The reason for this is that I don't like having to read (and understand the implications of) other specs to implement common behavior. At the same time, I feel that both Asbjorn's and Antone's proposals would be more difficult to implement than necessary. [1] http://www.intertwingly.net/wiki/pie/paceDateKarlGuertin If I've messed up some formatting or protocol, I beg your forgiveness. Cheers. Karl Guertin From owner-atom-syntax@mail.imc.org Thu Aug 12 18:59:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15521 for ; Thu, 12 Aug 2004 18:59:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMkpd3040479; Thu, 12 Aug 2004 15:46:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CMkpie040478; Thu, 12 Aug 2004 15:46:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMko45040470 for ; Thu, 12 Aug 2004 15:46:51 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id DCCE87C1EE; Fri, 13 Aug 2004 01:39:45 +0200 (CEST) Date: Fri, 13 Aug 2004 00:48:46 +0200 To: "Dare Obasanjo" Subject: Date paces (was: Re: PaceDateSamRuby +1) Cc: Atom-Syntax References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20040812213201.52881.qmail@web41213.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 14:32:01 -0700 (PDT), Dare Obasanjo wrote: > There's only one date in PaceSamRuby. I don't see how any ambiguity > or interoperability issues can arrive from misinterpreting a single > date. The date in PaceSamRuby is ambiguous as specified. It is close to the definition of ambiguity. It can represent absolutely all dates it is possible to express in human language. It says that it «typically, will be associated with the creation or availability of the resource», but that's just typically. Nothing required there. What does PaceSamRuby's atom:d mean to you? To me, it means absolutely nothing. Well, it represents a date. Nothing more. > The one ambiguity from previous experience in RSS is resolved because > it is explicitly stated that the value of the date field can change. So the ambiguity of RSS' dc:date and pubDate is only because it isn't stated whether it should change or not? Yes, that's one ambiguous thing about those dates, but there are several other things that make them ambiguous. Even if pubDate says it's a date that «Indicates when the item was published», almost no one uses it as a published date. pubDate and dc:date is used as «display date», «modified date», «creation date», «issued date» etc. And all of these can change whenever the author or tool feels like it. 'pubDate', 'dc:date' and PaceDateSamRuby's 'atom:d' conveys absolutely no semantical meaning. They're all as ambiguous as you can get them, and this is something we're supposed to add text for in the Atom specification? Are we really going to specify and encourage ambiguity? > It is silly for the spec to try to dictate which dates clients should > display to users or use for sorting. I totally agree. That's why I don't see what PaceDateSamRuby or PaceDateKenMacLeod does differently in this regard than the other paces. > You can spec it if you want, I'll ignore it in my application and > do what I think is best for my users based on their feedback. I don't want to specify it. I thought you wanted it to be specified. > By the way none of these problems exist if we just adopt PaceSamRuby. Why not? Becuase atom:d can be just about any date? > So why are you holding up consensus by ratholing on these points then? Because I care about what publishers do. Very much so. > What is so wrong with using the existing and very clearly defined > dates in http://purl.org/rss/1.0/modules/dcterms/ It's wrong because Atom would then just encourage all tools, both on publisher and consumer side, to continue the current practice where absolutely no semantic is shared between them. If PaceDateSamRuby or PaceDateKenMacLeod strongly encouraged people to use the DC dates instead of the atom:* date(s), I would be happier, but I still think these few dates are so important that they should go in the core. Also, PaceDateSamRuby and PaceDateKenMacLeod don't explicitly specify a subjective date, which many people have expressed interest in. Or should atom:d be objective, subjective, created, issued, modified and display all at the same time? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 19:09:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16162 for ; Thu, 12 Aug 2004 19:09:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMuAaE041179; Thu, 12 Aug 2004 15:56:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CMuAAp041178; Thu, 12 Aug 2004 15:56:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMu9kw041157 for ; Thu, 12 Aug 2004 15:56:10 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 392227C1EE; Fri, 13 Aug 2004 01:49:04 +0200 (CEST) Date: Fri, 13 Aug 2004 00:58:07 +0200 To: "Andreas Sewe" Subject: Re: On PaceDateSamRuby and PaceDateKenMacLeod Cc: Atom-Syntax References: <000c01c480b4$f52c3440$1757f7d9@baron> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <000c01c480b4$f52c3440$1757f7d9@baron> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 23:40:07 +0200, Andreas Sewe wrote: > "Consumers MAY chose to sort based on this value". To this user-agent > centric date the dcterm dates are mostly orthogonal as they reflect > the publishing process more than the user/presentation aspect. Is PaceDateSamRuby and PaceDateKenMacLeod specifying a subjective? I can't read that into the specification text in either of them. If it's meant to be subjective, and that all objective more publishing process-related dates should go in the DCTerms namespace, the paces should state so. Now they only specify that the DCTerms dates are needed because the atom:* date(s) can't represent «created», for example. When the specification needs to point to external date elements to cater for such a simple use case as «created», I think it's a good reason to include «created» (whatever we may choose to call it) in the specification. > Why preferring one subset of dcterm dates over another? Because some are more useful than others. The ones specified in my pace(s) at the moment, are the ones I would like to see used as soon as possible. The other DCTerms dates aren't that important, but if consumers or producers of Atom start asking for them, we should of course think about including them in the Atom namespace and define their uasge in Atom (version 1.1 for example). > I'm not sure I like this. IMHO a real supersedes mechanism would be > better. That's something I can agree with. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 19:09:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16207 for ; Thu, 12 Aug 2004 19:09:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMxxto041598; Thu, 12 Aug 2004 15:59:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CMxxaE041597; Thu, 12 Aug 2004 15:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMxvqd041580 for ; Thu, 12 Aug 2004 15:59:58 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 5298C7C1EE; Fri, 13 Aug 2004 01:52:53 +0200 (CEST) To: "Ken MacLeod" Cc: Atom-Syntax Subject: Versioning (was: Re: On PaceDateSamRuby and PaceDateKenMacLeod) References: <000c01c480b4$f52c3440$1757f7d9@baron> Message-ID: Date: Fri, 13 Aug 2004 01:01:56 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 12 Aug 2004 17:41:05 -0500, Ken MacLeod wrote: > Although I'm concerned about the irreversability of this decision with > respect to versioning, if no one sees value in either case I'm fine > with withdrawing the proposal. I think versioning is important, and I think Atom should not be locked from allowing extensions to define versioning. I've slowly begun to think that versioning can be done without changing the atom:id, and that a version:id is a good way to go. Still, I don't know how such a mechanism can impact the current Atom core specification. If we need to specify e.g. that atom:id MAY appear several times in a feed to cover future revisioning systems, we should do so. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 19:16:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16530 for ; Thu, 12 Aug 2004 19:16:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CN7C1x042255; Thu, 12 Aug 2004 16:07:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CN7CB7042254; Thu, 12 Aug 2004 16:07:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CN7Bu6042223 for ; Thu, 12 Aug 2004 16:07:12 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 979E87C1EE; Fri, 13 Aug 2004 02:00:05 +0200 (CEST) Date: Fri, 13 Aug 2004 01:09:11 +0200 To: grayrest Subject: Re: paceDateKarlGuertin Cc: Atom-Syntax References: <476b71e80408121521644a6550@mail.gmail.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <476b71e80408121521644a6550@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 18:21:50 -0400, grayrest wrote: > Hi all. I've thrown my own proposal [1] on the fire. I think you should read this message from Paul so that your pace can conform more to his guidelines: You should for example not use full date names for the elements, since those are baked with different meaning for all readers. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 19:22:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16998 for ; Thu, 12 Aug 2004 19:22:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CND9xG043969; Thu, 12 Aug 2004 16:13:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CND9Mh043968; Thu, 12 Aug 2004 16:13:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CND8og043950 for ; Thu, 12 Aug 2004 16:13:08 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7CND853023791 for ; Thu, 12 Aug 2004 18:13:08 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i7CND84I023787; Thu, 12 Aug 2004 18:13:08 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom-Syntax Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> From: Ken MacLeod Date: 12 Aug 2004 18:13:08 -0500 In-Reply-To: Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7CND9og043963 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg writes: > It's wrong because Atom would then just encourage all tools, both on > publisher and consumer side, to continue the current practice where > absolutely no semantic is shared between them. If PaceDateSamRuby or > PaceDateKenMacLeod strongly encouraged people to use the DC dates > instead of the atom:* date(s), I would be happier, but I still think > these few dates are so important that they should go in the core. The DC date element and the DC qualified date elements provide semantics for informational dates. I'm mostly concerned about processing and spec text that describes that processing. I'm fine with adopting all of DC as "informational" elements, and I think that's what Sam's reference to the dcterms module is proposing. > Also, PaceDateSamRuby and PaceDateKenMacLeod don't explicitly > specify a subjective date, which many people have expressed interest > in. Or should atom:d be objective, subjective, created, issued, > modified and display all at the same time? PaceDateSamRuby and PaceDateKenMacLeod The "atom:d" element's content conveys a date associated with an event in the life cycle of the entry. This does not suggest that atom:d is a "mechanical" date generated by the system, it may be any date that the publishing system or user selects as a date associated with an event in the life cycle of the entry. -- Ken From owner-atom-syntax@mail.imc.org Thu Aug 12 19:28:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17453 for ; Thu, 12 Aug 2004 19:28:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CNM4kN045293; Thu, 12 Aug 2004 16:22:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CNM4N2045292; Thu, 12 Aug 2004 16:22:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7CNM43t045212 for ; Thu, 12 Aug 2004 16:22:04 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040812232204.97183.qmail@web41207.mail.yahoo.com> Received: from [207.46.238.137] by web41207.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 16:22:04 PDT Date: Thu, 12 Aug 2004 16:22:04 -0700 (PDT) From: Dare Obasanjo Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) To: "Asbjørn_Ulsberg" Cc: Atom-Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Asbjørn_Ulsberg wrote: > > > What is so wrong with using the existing and very > clearly defined > > dates in http://purl.org/rss/1.0/modules/dcterms/ > > It's wrong because Atom would then just encourage > all tools, both on > publisher and consumer side, to continue the current > practice where > absolutely no semantic is shared between them. Huh ?!? The semantics in dc:terms are extremely clear to me. It seems you are claiming that if an extension exists it won't be widely supported which completely flies in the face of experience in the syndication world. If your application wants to express all sorts of fine grained date information about an entry use the dcterms:* elements which have a mechanism for providing this. If enough feeds do this then client support will appear. Heck lots of clients support a element even though it isn't specced anywhere simply because the need existed and people started using it. > If > PaceDateSamRuby or > PaceDateKenMacLeod strongly encouraged people to use > the DC dates instead > of the atom:* date(s), I would be happier, but I > still think these few > dates are so important that they should go in the > core. You think some arbitrary subset of the dcterms:* dates are important. I think some other arbitrary subset are important. Everyone who's posted about dates has seemed a different subset of these dates as important. The proper compromise would be for atom to use the superset of these dates which are those defined in dcterms. To me the only question then is whether Atom replicates all of the dcterms elements or recommends that people use them instead and provide only the lowest common denominator needed. Either solution works for me. Picking some random subset of these dates and moving them into the core is the worst of both worlds. Now I have to mix and match with dcterms if I want to use professional publishing terms in my application but have to be careful not to conflict with the random ones that exist in Atom. > Also, PaceDateSamRuby and PaceDateKenMacLeod don't > explicitly specify a > subjective date, which many people have expressed > interest in. Or should > atom:d be objective, subjective, created, issued, > modified and display all > at the same time? What is pubDate in RSS now? That is atom:d in PaceDateSamRuby. Every blogging tool today that supports a subjective date uses pubDate so I'm pretty sure they can use atom:d for it as well. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 12 19:47:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17966 for ; Thu, 12 Aug 2004 19:47:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CNZia7046374; Thu, 12 Aug 2004 16:35:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CNZiKb046373; Thu, 12 Aug 2004 16:35:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CNZh9k046365 for ; Thu, 12 Aug 2004 16:35:44 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id D918D7C1EE; Fri, 13 Aug 2004 02:28:37 +0200 (CEST) To: "Ken MacLeod" Cc: Atom-Syntax Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> Message-ID: Date: Fri, 13 Aug 2004 01:37:41 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 12 Aug 2004 18:13:08 -0500, Ken MacLeod wrote: > The DC date element and the DC qualified date elements provide > semantics for informational dates. I'm mostly concerned about > processing and spec text that describes that processing. I'm fine > with adopting all of DC as "informational" elements, and I think > that's what Sam's reference to the dcterms module is proposing. I don't get that feeling from Sam's proposal. If that's the intent, it should be made much clearer. > PaceDateSamRuby and PaceDateKenMacLeod > The "atom:d" element's content conveys a date associated with an > event in the life cycle of the entry. > > This does not suggest that atom:d is a "mechanical" date generated by > the system, it may be any date that the publishing system or user > selects as a date associated with an event in the life cycle of the > entry. Yes. But you do agree that this is very ambiguous, right? Is it possible to have any idea of what a publisher means with this date, without doing publishing system sniffing somehow? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 20:11:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19036 for ; Thu, 12 Aug 2004 20:11:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CNwsau048883; Thu, 12 Aug 2004 16:58:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CNwsKh048882; Thu, 12 Aug 2004 16:58:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CNwqHj048876 for ; Thu, 12 Aug 2004 16:58:53 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 4969C7C1EE; Fri, 13 Aug 2004 02:51:48 +0200 (CEST) Date: Fri, 13 Aug 2004 01:59:58 +0200 To: "Dare Obasanjo" Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) Cc: Atom-Syntax References: <20040812232204.97183.qmail@web41207.mail.yahoo.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20040812232204.97183.qmail@web41207.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 16:22:04 -0700 (PDT), Dare Obasanjo wrote: > The semantics in dc:terms are extremely clear to me. > It seems you are claiming that if an extension exists > it won't be widely supported which completely flies in > the face of experience in the syndication world. Then let me ask this simple question: isn't absolutely all Dublin Core dates available to RSS 1.0 and 2.0 today? If your answer to this question is «yes», then can you tell me why pubDate and dc:date is still used ambiguously? If there was need for any publishing tools to use the Dublin Core dates, they would have done so already. But they haven't. Thus, current practice works just fine for all publishers. Why would anyone change current practice when delivering Atom content, if the Atom specification don't even try to encourage anyone to do so? > If your application wants to express all sorts of fine > grained date information about an entry use the > dcterms:* elements which have a mechanism for > providing this. If enough feeds do this then client > support will appear. I'm not primarily a publisher. I at least don't speak as a publisher here, because what I do with Atom is nothing I want to bother the format with. If I want to use an 'http://asbjorn/' namespace for my elements, I'll do so. I am, as a consumer, interested in mildly forcing publishers to share semantics. If or when publishers use the Dublin Core elements (in or outside of Atom's namespace), I can be pretty confident that the content of these elements mean the same across all feeds. With Sam and Ken's proposals, however, the date we're left with means nothing. It caters for current practice, yes, but it doesn't improve anything, at least not for my part. Encouraging publishers to be more thoughtful in the dates they provide, and get them all to share common semantics, will improve the situation greatly. > Heck lots of clients support a element > even though it isn't specced anywhere simply because > the need existed and people started using it. Yes. And that's a great example of why the more fine-grained Dublin Core date elements _won't_ be used in Atom: They're not used in RSS. > You think some arbitrary subset of the dcterms:* dates > are important. I think some other arbitrary subset are > important. Everyone who's posted about dates has > seemed a different subset of these dates as important. According to the date survey, that's not the impression I get. We all share some kind of semantic in what dates we want, but we all want different things. > The proper compromise would be for atom to use the > superset of these dates which are those defined in > dcterms. If those are explicitly defined in the Atom specification, I can go along with having these dates in the Dublin Core namespace. > To me the only question then is whether Atom replicates > all of the dcterms elements or recommends that people > use them instead and provide only the lowest common > denominator needed. That's the problem: there _is_ no «lowest common denominator». The date proposed in Sam and Ken's proposal, is a collection of all dates imaginable.It's not common, it's not lowest and it's definately not a denominator. It's as wide, high and broad as you can get it. > What is pubDate in RSS now? That is atom:d in PaceDateSamRuby. Yes. > Every blogging tool today that supports a subjective date uses > pubDate so I'm pretty sure they can use atom:d for it as well. Of course. But the problem is that they squeeze any objective date into it as well. Infact, they squeeze _all_ dates they have available in that element, no matter what dates that may be. «You have 'modified'? Use pubDate. You have 'created'? Use pubDate. You have 'issued'? Use pubDate.» -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 20:26:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19771 for ; Thu, 12 Aug 2004 20:26:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0DUCM050098; Thu, 12 Aug 2004 17:13:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0DUtY050097; Thu, 12 Aug 2004 17:13:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0DTJC050059 for ; Thu, 12 Aug 2004 17:13:30 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 13 Aug 2004 10:19:28 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 Aug 2004 10:12:57 +1000 Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20040812232204.97183.qmail@web41207.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 13/8/04 9:22 AM, "Dare Obasanjo" wrote: > Either solution works for me. Picking some random > subset of these dates and moving them into the core is > the worst of both worlds. Now I have to mix and match > with dcterms if I want to use professional publishing > terms in my application but have to be careful not to > conflict with the random ones that exist in Atom. "random"? no one has suggested such a process at all. please refrain from such straw man arguments. e. From owner-atom-syntax@mail.imc.org Thu Aug 12 20:36:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20127 for ; Thu, 12 Aug 2004 20:36:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0KnIo050647; Thu, 12 Aug 2004 17:20:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0KnB5050646; Thu, 12 Aug 2004 17:20:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0Km0U050637 for ; Thu, 12 Aug 2004 17:20:48 -0700 (PDT) (envelope-from grayrest@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so371407rnl for ; Thu, 12 Aug 2004 17:20:36 -0700 (PDT) Received: by 10.38.82.46 with SMTP id f46mr1353029rnb; Thu, 12 Aug 2004 17:20:36 -0700 (PDT) Message-ID: <476b71e8040812172075d8dd78@mail.gmail.com> Date: Thu, 12 Aug 2004 20:20:36 -0400 From: grayrest To: Eric Scheid Subject: Re: paceDateKarlGuertin Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 13 Aug 2004 10:02:41 +1000, Eric Scheid wrote: > On 13/8/04 8:21 AM, "grayrest" wrote: > > > [1] http://www.intertwingly.net/wiki/pie/paceDateKarlGuertin > > > atom:d ("modified") > > > > If a provider cannot distinguish between significant and non-significant > > updates, the atom:c element SHOULD be present and the atom:d element MUST NOT > > be present. > > I think this is the wrong way around. You are muddying the special meaning > of atom:c by injecting the values which more properly should be in atom:d. I initially had this the other way around. I thought that atom:c would be the special case. I changed it in an attempt to make implementation easier. The though was "If atom:c is present the user will want to see that the entry has been updated. If atom:d is also present, the publisher wishes to notify the user that the edit was minor, which the user can choose to ignore. If a provider cannot provide both atom:c and atom:d, then atom:c should be provided and the user able to choose." If the current order/semantics sticks then I should go back and specify that there must be an atom:c for every atom:d. This could be written either way, it probably makes more sense to do it the other way. I'm updating the wiki. Eric's post continues: > There will be feeds where the publisher can and does provide atom:c (aka > "updated"), but cannot be trusted to do so in an ethical manner (eg. not > signalling major retractions, deletions, or corrections). For feeds such as > these, even though both atom:c and atom:d are present I would want to set a > preference in my reader of choice that I would like to see changes based on > atom:d. Given that flexibility, I would therefore be able to be notified of > changes in feeds which only supply atom:d and not atom:c. > > Of course, some aggregator developers won't provide any such flexibility. I > won't choose to use their software. > > e. > > From owner-atom-syntax@mail.imc.org Thu Aug 12 20:57:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21163 for ; Thu, 12 Aug 2004 20:57:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0icao053274; Thu, 12 Aug 2004 17:44:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0icpa053273; Thu, 12 Aug 2004 17:44:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41204.mail.yahoo.com (web41204.mail.yahoo.com [66.218.93.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7D0icBe053261 for ; Thu, 12 Aug 2004 17:44:38 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040813004439.88129.qmail@web41204.mail.yahoo.com> Received: from [207.46.238.138] by web41204.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 17:44:38 PDT Date: Thu, 12 Aug 2004 17:44:38 -0700 (PDT) From: Dare Obasanjo Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) To: "Asbjørn_Ulsberg" Cc: Atom-Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Asbjørn_Ulsberg wrote: > > Yes. And that's a great example of why the more > fine-grained Dublin Core > date elements _won't_ be used in Atom: They're not > used in RSS. This implies to me that no one wants this functionality not that people won't use extensions for stuff missing from the core spec. Again experience with RSS has shown that people will create and use extensions for stuff missing from the core that they actually need. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Thu Aug 12 21:02:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21444 for ; Thu, 12 Aug 2004 21:02:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0mrGE053599; Thu, 12 Aug 2004 17:48:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0mrBA053598; Thu, 12 Aug 2004 17:48:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0mqcN053587 for ; Thu, 12 Aug 2004 17:48:53 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 3DF427C1EE; Fri, 13 Aug 2004 03:41:49 +0200 (CEST) To: "Dare Obasanjo" Cc: Atom-Syntax Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) References: <20040813004439.88129.qmail@web41204.mail.yahoo.com> Message-ID: Date: Fri, 13 Aug 2004 02:50:11 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20040813004439.88129.qmail@web41204.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 17:44:38 -0700 (PDT), Dare Obasanjo wrote: > This implies to me that no one wants this functionality not that > people won't use extensions for stuff missing from the core spec. > Again experience with RSS has shown that people will create and use > extensions for stuff missing from the core that they actually need. So publishers rule all. They own the content, and content is king. How do we get the publishers to support dates that are useful to consumers without getting them into the specification? The publishers are already quite content with the one date element they have. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 12 21:10:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21782 for ; Thu, 12 Aug 2004 21:10:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D0fJYB052517; Thu, 12 Aug 2004 17:41:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D0fJ7i052516; Thu, 12 Aug 2004 17:41:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41201.mail.yahoo.com (web41201.mail.yahoo.com [66.218.93.34]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7D0fJrc052458 for ; Thu, 12 Aug 2004 17:41:19 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040813004120.43393.qmail@web41201.mail.yahoo.com> Received: from [131.107.76.30] by web41201.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 17:41:20 PDT Date: Thu, 12 Aug 2004 17:41:20 -0700 (PDT) From: Dare Obasanjo Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) To: Eric Scheid , Atom Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Eric Scheid wrote: > > On 13/8/04 9:22 AM, "Dare Obasanjo" > wrote: > > > Either solution works for me. Picking some random > > subset of these dates and moving them into the > core is > > the worst of both worlds. Now I have to mix and > match > > with dcterms if I want to use professional > publishing > > terms in my application but have to be careful not > to > > conflict with the random ones that exist in Atom. > > "random"? > > no one has suggested such a process at all. > > please refrain from such straw man arguments. To anyone who looks at the dcterms namespace elements and the subsets proposed in the various Paces what is the connection that one could draw? To me they look like a randomly chosen subset. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 12 21:18:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22120 for ; Thu, 12 Aug 2004 21:18:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1554Y055170; Thu, 12 Aug 2004 18:05:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D155fh055169; Thu, 12 Aug 2004 18:05:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D14oJJ055114 for ; Thu, 12 Aug 2004 18:04:58 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 13 Aug 2004 11:11:10 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 Aug 2004 11:04:40 +1000 Subject: dc:dates in atom - some questions From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit For those proposing we use the various dc:dates in atom, please answer some questions: [1] Will the atom spec be providing text which describes what format the dates will be in (eg. RFC 3339), and any other limitations or subset definitions? [2] Will this be valid in an atom feed: 1999-12-24 and if so, how will the various aggregator developers handle it? [3] With dc:modified, will we be providing any clarification text, since dc:modified is described with reference to terms of RSS. Will some publishers translate RSS terms to Atom terms, or will some say "that's specific to RSS, Atom is different, so I'm ignoring that bit of spec text"? http://web.resource.org/rss/1.0/modules/dcterms/#modified [4] With dc:modified, note that it says "It is recomended that the Modified date should correspond to the HTTP 1.1 Last-Modified date, of the document the element points to when Modified is used within a element". If translating to Atom, is this the element which points to the @rel="alternate" resource, or the resource which the entry is "about" (eg. when pointing at an external resource, the original model for RSS)? [5] Should I be using dcterms:available or dcterms:issued, and which ones will Shrook, RSS Bandit, NNW etc support or ignore? If the market by practice decides on dcterms:issued (and mostly ignores dcterms:available, thus resulting in aggregator clients ignoring same), should I stick my value for dcterms:available in dcterms:issued just so I can provide useful functionality to my consumers? http://web.resource.org/rss/1.0/modules/dcterms/#issued http://web.resource.org/rss/1.0/modules/dcterms/#available [5] Does everyone realise that, apart from the issue of dcterms allowing partial dates (eg. "2004-08"), some of the dc dates are not W3CDTF values at all, but are instead date *ranges*? For example, did you read the previous question thinking dcterms:available would be a date value, and not something like this: name=OO Perl / mod_perl programmer for Web CMS; start=2002-7-5; end=2002-8-5; scheme=W3C-DTF [6] Look closely at that last date construct ... will we be supporting the "scheme" sub-element, or mandating in the Atom spec that all dates must be in RFC 3339 format? [and will the anti-micro-parser crowd please chime in now too?] e. From owner-atom-syntax@mail.imc.org Thu Aug 12 21:28:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22464 for ; Thu, 12 Aug 2004 21:28:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1DNZs056035; Thu, 12 Aug 2004 18:13:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D1DNlo056034; Thu, 12 Aug 2004 18:13:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1DMmW056007 for ; Thu, 12 Aug 2004 18:13:22 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004081301132001600qttr7e>; Fri, 13 Aug 2004 01:13:21 +0000 Date: Thu, 12 Aug 2004 19:13:19 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceDateAntoneRoundy2 created From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceDateAntoneRoundy2 Based on the last few days' discussion, I've created one final proposal, after which I will almost surely be silent on this issue. PaceDateAntoneRoundy2 defines two Date Constructs, neither of which duplicates anything defined by dcterms. One of the two is required, and publishers are strongly encouraged to supply the more "objective" of the two. Publishers are encouraged to use dcterms dates for any additional time stamps they wish to express. From owner-atom-syntax@mail.imc.org Thu Aug 12 21:37:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22766 for ; Thu, 12 Aug 2004 21:37:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1Jr3e056557; Thu, 12 Aug 2004 18:19:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D1Jr2h056556; Thu, 12 Aug 2004 18:19:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1JpAB056549 for ; Thu, 12 Aug 2004 18:19:52 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 13 Aug 2004 11:22:09 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 Aug 2004 11:15:38 +1000 Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20040813004120.43393.qmail@web41201.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 13/8/04 10:41 AM, "Dare Obasanjo" wrote: > To anyone who looks at the dcterms namespace elements > and the subsets proposed in the various Paces what is > the connection that one could draw? To me they look > like a randomly chosen subset. For someone advocating people should go read what they are talking about, you don't seem to have read the reasonings provided for choosing those subsets. Disappointing. [and apologies for snarkiness] Admittedly, those reasonings are for why certain dates are selected, but silent on why others were omitted. Let me correct that then: -- selected -- selected -- selected -- is a date-range value, not a date value, which is not a semantic we are pursuing under the rubric of "date construct" -- is a date-range value, ditto as :valid -- though popular in academic publishing, isn't of particular interest to most RSS/Atom publishers at this time (dare I say) -- we already have a element in core, and we've been careful to have that element not be machine readable, leaving such to extensions. -- ditto as for dateAccepted When I take the time to read the reasonings it's not so random to me. e. From owner-atom-syntax@mail.imc.org Thu Aug 12 21:37:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22789 for ; Thu, 12 Aug 2004 21:37:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1NaSP056948; Thu, 12 Aug 2004 18:23:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D1Naek056947; Thu, 12 Aug 2004 18:23:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1NZqW056937 for ; Thu, 12 Aug 2004 18:23:36 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc11) with SMTP id <20040813012336011004oae9e>; Fri, 13 Aug 2004 01:23:36 +0000 Date: Thu, 12 Aug 2004 19:23:35 -0600 Subject: Re: dc:dates in atom - some questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <6563D963-ECC7-11D8-A471-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 12, 2004, at 07:04 PM, Eric Scheid wrote: > [1] Will the atom spec be providing text which describes what format > the > dates will be in (eg. RFC 3339), and any other limitations or subset > definitions? At least some of these proposals, if not all, say that they SHOULD be in the more restricted format, but don't REQUIRE it. > [5] Should I be using dcterms:available or dcterms:issued I thought the difference between the two was pretty clear: available = the date range during which the publisher wishes the entry to be presented to the user. issued = when the entry was actually published. Use the one that means what you want to say. > If the market by > practice decides on dcterms:issued (and mostly ignores > dcterms:available, > thus resulting in aggregator clients ignoring same), should I stick my > value > for dcterms:available in dcterms:issued just so I can provide useful > functionality to my consumers? If you want people to see your entry beginning at some particular time, and available isn't widely supported, then wait till that time to publish it rather than fudging the value of issued--that'd be my preference. > http://web.resource.org/rss/1.0/modules/dcterms/#issued > http://web.resource.org/rss/1.0/modules/dcterms/#available From owner-atom-syntax@mail.imc.org Thu Aug 12 21:39:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22877 for ; Thu, 12 Aug 2004 21:39:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1Rjfr057262; Thu, 12 Aug 2004 18:27:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D1RjMe057261; Thu, 12 Aug 2004 18:27:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1RiBZ057252 for ; Thu, 12 Aug 2004 18:27:44 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <20040813012745013001cg2ue>; Fri, 13 Aug 2004 01:27:45 +0000 Date: Thu, 12 Aug 2004 19:27:44 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceDateAntoneRoundy withdrawn From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Given that the likelihood of gaining consensus around PaceDateAntoneRoundy is extremely slim, and given that I'd be entirely satisfied with PaceDateAntoneRoundy2, which I think has much better chances, I'm withdrawing my support for PaceDateAntoneRoundy. Anyone opposed to closing it? From owner-atom-syntax@mail.imc.org Thu Aug 12 22:02:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24122 for ; Thu, 12 Aug 2004 22:02:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMfB1S040110; Thu, 12 Aug 2004 15:41:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CMfBUZ040109; Thu, 12 Aug 2004 15:41:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CMf8lm040098 for ; Thu, 12 Aug 2004 15:41:10 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7CMf553023456 for ; Thu, 12 Aug 2004 17:41:05 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i7CMf5gI023452; Thu, 12 Aug 2004 17:41:05 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Subject: Re: On PaceDateSamRuby and PaceDateKenMacLeod References: <000c01c480b4$f52c3440$1757f7d9@baron> From: Ken MacLeod Date: 12 Aug 2004 17:41:05 -0500 In-Reply-To: <000c01c480b4$f52c3440$1757f7d9@baron> Message-ID: Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Andreas Sewe" writes: > Now PaceDateKenMacLeod too includes a date which is defined > similarily in dcterms: atom:e (which, at least to me, looks similar > to dcterms:modified). It has additional implicitions though, because > it is meant as some kind of entry versioning mechanism: > > "Publishers may provide more than one instance or version of the > same atom:entry within the same atom:feed (ie. with equivalent > atom:id values), consumers MAY choose to only record, process, or > present the atom:entry with the latest atom:e value." > > I'm not sure I like this. IMHO a real supersedes mechanism would be > better. Earlier, Dare Obasanjo wrote: > Using dates as a versioning mechanism seemed like a hack to me. I > definitely oppose all efforts to conflate the date issue with > versioning. I'd like to clarify that PaceDateKenMacLeod's atom:e is not and is not intended to be a versioning mechanism (by itself it can't be, for a variety of reasons). As one of its use cases, however, it does allow a future extension to define a versioning mechanism that will work with Atom 1.0 clients by virtue of telling Atom 1.0 clients what to do when they see more than one entry in the same feed with the same atom:id: only use the latest. Although that's not a strong current use case (at least our folks who desire versioning have seemed to have backed off on requesting multiple entries with the same story id), it's also one we can't change our minds on in the future and remain backwards compatible. An alternative proposal for versioning suggests a more significant backwards incompatibility: changing the atom:id itself for new versions. The other principle use case is to mark a possible change in the entry that gives a consumer a first indication of whether they need to do any further processing on the entry. However, it's a weak indicator since most processors have the time to hash every entry anyway. Although I'm concerned about the irreversability of this decision with respect to versioning, if no one sees value in either case I'm fine with withdrawing the proposal. -- Ken MacLeod From owner-atom-syntax@mail.imc.org Thu Aug 12 22:18:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24930 for ; Thu, 12 Aug 2004 22:18:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D1wC1s059671; Thu, 12 Aug 2004 18:58:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D1wC6U059670; Thu, 12 Aug 2004 18:58:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7D1wBit059662 for ; Thu, 12 Aug 2004 18:58:11 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040813015812.70602.qmail@web41202.mail.yahoo.com> Received: from [131.107.76.143] by web41202.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 18:58:12 PDT Date: Thu, 12 Aug 2004 18:58:12 -0700 (PDT) From: Dare Obasanjo Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) To: Eric Scheid , Atom Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Eric Scheid wrote: > > For someone advocating people should go read what > they are talking about, > you don't seem to have read the reasonings provided > for choosing those > subsets. Disappointing. [and apologies for > snarkiness] > > Admittedly, those reasonings are for why certain > dates are selected, but > silent on why others were omitted. Let me correct > that then: > > -- selected > -- selected > -- selected > > -- is a date-range value, not a date > value, which is not a > semantic we are pursuing under the rubric of "date > construct" This is optionally a range. I can imagine news sites would get some use out of having such a date construct. > -- is a date-range value, ditto > as :valid This is optionally a range. Also I've seen people talk about dcterms:available in the discussions about dates especially since this is more inline with informal publishing on the web than dcterms:issued. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Thu Aug 12 22:24:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25123 for ; Thu, 12 Aug 2004 22:24:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D291wE060299; Thu, 12 Aug 2004 19:09:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D291L6060298; Thu, 12 Aug 2004 19:09:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D28xqv060292 for ; Thu, 12 Aug 2004 19:09:00 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 13 Aug 2004 12:15:25 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 Aug 2004 12:08:56 +1000 Subject: Re: Date paces (was: Re: PaceDateSamRuby +1) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20040813015812.70602.qmail@web41202.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 13/8/04 11:58 AM, "Dare Obasanjo" wrote: >> -- is a date-range value, not a date >> value, which is not a >> semantic we are pursuing under the rubric of "date >> construct" > > This is optionally a range. I can imagine news sites > would get some use out of having such a date > construct. > >> -- is a date-range value, ditto >> as :valid > > This is optionally a range. Also I've seen people talk > about dcterms:available in the discussions about dates > especially since this is more inline with informal > publishing on the web than dcterms:issued. will you be supporting date ranges in your aggregator implementation, or will you be borking/ignoring date ranges? do you believe the atom spec should specify whether date ranges are optional, or whether dcterms:available and dcterms:valid MUST be RFC 3339? e. From owner-atom-syntax@mail.imc.org Thu Aug 12 22:33:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25390 for ; Thu, 12 Aug 2004 22:33:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D2BT73060763; Thu, 12 Aug 2004 19:11:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D2BTQk060762; Thu, 12 Aug 2004 19:11:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D2BS2X060747 for ; Thu, 12 Aug 2004 19:11:29 -0700 (PDT) (envelope-from grayrest@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so405rnk for ; Thu, 12 Aug 2004 19:11:32 -0700 (PDT) Received: by 10.38.74.10 with SMTP id w10mr8810rna; Thu, 12 Aug 2004 19:11:30 -0700 (PDT) Message-ID: <476b71e804081219115d1f23be@mail.gmail.com> Date: Thu, 12 Aug 2004 22:11:30 -0400 From: grayrest To: Eric Scheid Subject: Re: dc:dates in atom - some questions Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 13 Aug 2004 11:04:40 +1000, Eric Scheid wrote: > For those proposing we use the various dc:dates in atom, please answer some > questions: > > [1] Will the atom spec be providing text which describes what format the > dates will be in (eg. RFC 3339), and any other limitations or subset > definitions? This is specified in my pace. It may not be explicit but the intent is to have any date formatting in the dc:dates extension mechanism use the exact same formatting as the rest of the dates. I doubt that I'm going to find a useful dc:dates parsing library in (e.g.) javascript, so I'd have to re-implement this myself and it's just easier if there is one and only one format to the dates. > [2] Will this be valid in an atom feed: > 1999-12-24 > and if so, how will the various aggregator developers handle it? No. Times and timezones must be specified. > [3] With dc:modified, will we be providing any clarification text, since > dc:modified is described with reference to terms of RSS. Will some > publishers translate RSS terms to Atom terms, or will some say "that's > specific to RSS, Atom is different, so I'm ignoring that bit of spec text"? I believe the 80% use case is explicitly defined in my proposal, dcdates is only provided as a recommended extension mechanism so that tool wishing to extend the api do so in the same direction. If a particular item becomes a de facto standard, then it should be officially amended to the next version of the Atom syntax to become de jure. > [4] With dc:modified, note that it says "It is recomended that the Modified..." Specified, not an issue. > [5] Should I be using dcterms:available or dcterms:issued, and which ones > will Shrook, RSS Bandit, NNW etc support or ignore? I hope that atom:a is the obvious target for developers to display and that other common consumer wants are covered without having to choose which to show and which to ignore. It is expected that all conforming consumers be able to handle at least three (a,b,d) and preferably c as well. If I'm missing a common use case, please propose an amendment. > [5] Does everyone realise that, apart from the issue of dcterms allowing > partial dates (eg. "2004-08"), some of the dc dates are not W3CDTF values at > all, but are instead date *ranges*? I do not believe these fall into common usage, hence their status as preferreed extensions. > [6] Look closely at that last date construct ... will we be supporting the > "scheme" sub-element, or mandating in the Atom spec that all dates must be > in RFC 3339 format? [and will the anti-micro-parser crowd please chime in > now too?] I'm pro-micro-parser, if you haven't gathered. Parsers I write won't support any extensions unless market pressures force me into it. From owner-atom-syntax@mail.imc.org Fri Aug 13 07:54:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08745 for ; Fri, 13 Aug 2004 07:54:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DBdKuE047275; Fri, 13 Aug 2004 04:39:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DBdKhQ047274; Fri, 13 Aug 2004 04:39:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from journurl.com (69-56-184-50.theplanet.com [69.56.184.50] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DBdJir047185 for ; Fri, 13 Aug 2004 04:39:20 -0700 (PDT) (envelope-from roger@agincourtmedia.com) Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Fri, 13 Aug 2004 06:39:11 -0500 From: "Roger B." To: "'Antone Roundy'" , Subject: RE: PaceDateAntoneRoundy2 created Date: Fri, 13 Aug 2004 06:44:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSA0tBVBVhBSqC+TIa7xYWQSxQRRAAVtQ7g Message-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone: It meets my absolute needs in both my roles, and the descriptions of the elements are different enough that I think we'd be relatively safe from confusing template-tweaking users. I still prefer PDSamRuby for its simplicity, but you're getting very close to that. If it would help with consensus, I would strongly consider giving this a +1. -- Roger Benningfield JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Aug 13 07:57:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09057 for ; Fri, 13 Aug 2004 07:57:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DBjW6W049631; Fri, 13 Aug 2004 04:45:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DBjWqc049630; Fri, 13 Aug 2004 04:45:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DBjVTs049605 for ; Fri, 13 Aug 2004 04:45:31 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 54907 invoked from network); 13 Aug 2004 11:45:29 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 13 Aug 2004 11:45:29 -0000 Received: from 194.203.191.188 ([194.203.191.188]) by webmail.djpowell.net (IMP) with HTTP for ; Fri, 13 Aug 2004 12:45:29 +0100 Message-ID: <1092397529.411ca9d96959e@webmail.djpowell.net> Date: Fri, 13 Aug 2004 12:45:29 +0100 From: David Powell To: Ken MacLeod Cc: Atom-Syntax Subject: Using DC only for informational dates (was: Re: Date paces) References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 194.203.191.188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Ken MacLeod : > The DC date element and the DC qualified date elements provide > semantics for informational dates. I'm mostly concerned about > processing and spec text that describes that processing. I'm fine > with adopting all of DC as "informational" elements, and I think > that's what Sam's reference to the dcterms module is proposing. I would be ok with using DC to represent all "informational" dates (such as dc:issued, dc:created, etc), but I think that some dates are expected to have behaviours associated with them - and I'm not comfortable with specifying behaviours for DC dates, which I believe are intended to be mostly informational. If atom agents would be expected to associate behaviours with certain dates then I'd rather those dates be inlined and fully specified by Atom. These two dates have significant behaviours: "date of minor modification" - if included could be used by indexers and processors to not process entries that had not changed. Like a Last-Modified header for entries. "date of significant update" - if included a client might alert the user to an update in a mutable entry. (Note I'm not necessary suggesting that "date of significant update" should be included in atom - just that if it were it would have a significant behaviour) Also I think that "display date" needs to be specified within Atom because it isn't part of DC. I probably ought to write this up as a Pace to avoid reintroducing ambiguous date terms back into the discussion. > PaceDateSamRuby and PaceDateKenMacLeod > The "atom:d" element's content conveys a date associated with an > event in the life cycle of the entry. > > This does not suggest that atom:d is a "mechanical" date generated by > the system, it may be any date that the publishing system or user > selects as a date associated with an event in the life cycle of the > entry. Well it does seem to exclude "display date" from the definition because "display date" is a date associated with the content of the entry, not necessarily with the publishing life-cycle. Perhaps excluding it wasn't intended though? Sam? -- Dave From owner-atom-syntax@mail.imc.org Fri Aug 13 14:01:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02097 for ; Fri, 13 Aug 2004 14:01:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHnnGK043590; Fri, 13 Aug 2004 10:49:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHnnTx043589; Fri, 13 Aug 2004 10:49:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHnlif043577 for ; Fri, 13 Aug 2004 10:49:48 -0700 (PDT) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BvgBa-00056A-00; Fri, 13 Aug 2004 19:49:50 +0200 Received: from [217.247.86.103] (helo=baron) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BvgBa-0007sI-00; Fri, 13 Aug 2004 19:49:50 +0200 Message-ID: <002601c4815e$16d84e40$955cf7d9@baron> From: "Andreas Sewe" To: "[Atom]" , "Antone Roundy" References: Subject: Requiring UTC - Was: PaceDateAntoneRoundy2 created Date: Fri, 13 Aug 2004 19:50:46 +0200 Organization: Fachbereich Informatik, TU Darmstadt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:275eb74a6eb9feb006a62452721ee94c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Almost the only part I somewhat dislike is that the pace unnessecarily requires the use of UTC for atom:c. Quoting : > atom:c MUST be expressed in UTC. Thus, it MUST include one of the following > time zone designators: "+00:00", "-00:00" or "Z"." Why not allow any timezones, as long as one is present? Converting dates to different timezones is easy enough, and I bet a lot of informational dates added using DCTerms will use other time zones than UTC, too. Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Fri Aug 13 14:09:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02526 for ; Fri, 13 Aug 2004 14:09:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHxFcN044680; Fri, 13 Aug 2004 10:59:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHxFFL044679; Fri, 13 Aug 2004 10:59:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHxEwU044667 for ; Fri, 13 Aug 2004 10:59:15 -0700 (PDT) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BvgKj-00053U-00; Fri, 13 Aug 2004 19:59:17 +0200 Received: from [217.247.84.72] (helo=baron) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BvgKi-0002af-00; Fri, 13 Aug 2004 19:59:16 +0200 Message-ID: <003701c4815f$684efde0$955cf7d9@baron> From: "Andreas Sewe" To: "Antone Roundy" , "[Atom]" References: Subject: An issue to clarify - Was: PaceDateAntoneRoundy2 created Date: Fri, 13 Aug 2004 20:00:12 +0200 Organization: Fachbereich Informatik, TU Darmstadt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:275eb74a6eb9feb006a62452721ee94c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > Based on the last few days' discussion, I've created one final > proposal, after which I will almost surely be silent on this issue. > PaceDateAntoneRoundy2 defines two Date Constructs, neither of which > duplicates anything defined by dcterms. One of the two is required, > and publishers are strongly encouraged to supply the more "objective" > of the two. Basically I like the pace quite a lot. It seems to contradict itself though: Neither > atom:entry elements SHOULD contain an atom:c element, but MUST NOT contain > more than one. nor > atom:entry elements MAY contain an atom:d element, but MUST NOT contain more > than one. requires the presence of a date construct. So is the text of the abstract ("One of the two is required, and publishers are strongly encouraged to supply the more "objective" of the two) intended to be normative, or should the SHOULD be a MUST instead? Personally I prefer the latter interpretation. Antone, can please you clarify this issue? Thanks. Andreas Sewe From owner-atom-syntax@mail.imc.org Fri Aug 13 14:31:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03614 for ; Fri, 13 Aug 2004 14:31:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIHgRM046941; Fri, 13 Aug 2004 11:17:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DIHgvD046940; Fri, 13 Aug 2004 11:17:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIHd7J046919 for ; Fri, 13 Aug 2004 11:17:41 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <200408131817360130016a37e>; Fri, 13 Aug 2004 18:17:36 +0000 Date: Fri, 13 Aug 2004 12:17:35 -0600 Subject: Re: An issue to clarify - Was: PaceDateAntoneRoundy2 created Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <003701c4815f$684efde0$955cf7d9@baron> Message-Id: <0CE172A6-ED55-11D8-BDB3-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, August 13, 2004, at 12:00 PM, Andreas Sewe wrote: > Neither >> atom:entry elements SHOULD contain an atom:c element, but MUST NOT >> contain >> more than one. > nor >> atom:entry elements MAY contain an atom:d element, but MUST NOT >> contain more >> than one. > > requires the presence of a date construct. So is the text of the > abstract > ("One of the two is required, and publishers are strongly encouraged > to supply > the more "objective" of the two) intended to be normative, or should > the > SHOULD be a MUST instead? Personally I prefer the latter > interpretation. > The normative text is "Each atom:entry MUST contain one or more of the following Date Constructs." in section 5.6. But (primarily) because some systems will not be able to provide atom:c, it is a SHOULD instead of a MUST. Perhaps the final spec text could be more explicit about saying that the worst case is that a date of unknown significance to the entry gets put into atom:d. From owner-atom-syntax@mail.imc.org Fri Aug 13 14:34:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03772 for ; Fri, 13 Aug 2004 14:34:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIN6W7047622; Fri, 13 Aug 2004 11:23:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DIN6wW047621; Fri, 13 Aug 2004 11:23:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIN62G047605 for ; Fri, 13 Aug 2004 11:23:06 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc13) with SMTP id <20040813182305015008ubnae>; Fri, 13 Aug 2004 18:23:05 +0000 Date: Fri, 13 Aug 2004 12:23:04 -0600 Subject: Re: Requiring UTC - Was: PaceDateAntoneRoundy2 created Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <002601c4815e$16d84e40$955cf7d9@baron> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, August 13, 2004, at 11:50 AM, Andreas Sewe wrote: > Almost the only part I somewhat dislike is that the pace unnessecarily > requires the use of UTC for atom:c. > > Quoting : >> atom:c MUST be expressed in UTC. Thus, it MUST include one of the >> following >> time zone designators: "+00:00", "-00:00" or "Z"." > > Why not allow any timezones, as long as one is present? Converting > dates to > different timezones is easy enough, and I bet a lot of informational > dates > added using DCTerms will use other time zones than UTC, too. > During previous discussion, some have expressed the desire to have dates constrained to UTC to enable simple string sorting rather than having to parse dates. Note that the date construct that is intended to take more of a display date type role is NOT constrained to any particular time zone. If it is decided that we don't want to constrain the time zones of any of the dates, that's fine with me. From owner-atom-syntax@mail.imc.org Fri Aug 13 15:06:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06793 for ; Fri, 13 Aug 2004 15:06:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIsJWO051363; Fri, 13 Aug 2004 11:54:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DIsJRx051362; Fri, 13 Aug 2004 11:54:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIsIx0051351 for ; Fri, 13 Aug 2004 11:54:18 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7DIsDJ6029850 for ; Fri, 13 Aug 2004 11:54:17 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I2E00001F2CBT@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Fri, 13 Aug 2004 14:54:13 -0400 (EDT) Received: from mercury (vpn-129-150-33-164.Central.Sun.COM [129.150.33.164]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I2E00C7OF6CAY@bur-mail1.east.sun.com> for atom-syntax@imc.org; Fri, 13 Aug 2004 14:54:13 -0400 (EDT) Received: from ndw by mercury with local (Exim 3.36 #1 (Debian)) id 1BvhBg-0004Gj-00 for ; Fri, 13 Aug 2004 14:54:00 -0400 X-URL: http://nwalsh.com/ Date: Fri, 13 Aug 2004 14:53:57 -0400 From: Norman Walsh Subject: Re: PaceDateSamRuby -1 In-reply-to: <38445FBE-EC86-11D8-B7AB-000A95DC3D90@mac.com> To: Atom Syntax Message-id: <87u0v6x41m.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) References: <20040812170948.53680.qmail@web41201.mail.yahoo.com> <38445FBE-EC86-11D8-B7AB-000A95DC3D90@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain / Graham was heard to say: | On 12 Aug 2004, at 12:09 pm, Dare Obasanjo wrote: | |> Interesting. I assume you haven't read their spec then. Looking at |> http://web.resource.org/rss/1.0/modules/dcterms/ I don't see how |> they are any worse defined than any of the proposals on the Atom |> list. In fact, I have found them less ambiguous and prone to |> misinterpretation than the dates I saw proposed in the two other |> Paces I read yesterday. | | You're right, I haven't looked at it in a while, but I remember it | being thin. I don't see anything much about revisions to documents, | which is the big thing that separates syndication from, say, email. | The process those dates are built around isn't one where the document | appears to change ever. What Dare said earlier in this thread: "Using dates as a versioning mechanism seemed like a hack to me. I definitely oppose all efforts to conflate the date issue with versioning." Be seeing you, norm -- Norman Walsh | You can pretend to be serious; you http://nwalsh.com/ | can't pretend to be witty.--Sacha Guitry --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBHQ5HOyltUcwYWjsRAt4wAJ0Rc3xJ+hyWFU++Kjhk/3nquxJQdwCeIhUk Lw2eomnr8mSR5BSlgk77jZE= =A+Nu -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Fri Aug 13 17:48:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19952 for ; Fri, 13 Aug 2004 17:48:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DLaANv065833; Fri, 13 Aug 2004 14:36:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DLaAlM065832; Fri, 13 Aug 2004 14:36:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DLa8BM065821 for ; Fri, 13 Aug 2004 14:36:09 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7DLa853006108 for ; Fri, 13 Aug 2004 16:36:08 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i7DLa7DF006104; Fri, 13 Aug 2004 16:36:07 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom Syntax Subject: Re: PaceDateSamRuby -1 References: <20040812170948.53680.qmail@web41201.mail.yahoo.com> <38445FBE-EC86-11D8-B7AB-000A95DC3D90@mac.com> <87u0v6x41m.fsf@nwalsh.com> From: Ken MacLeod Date: 13 Aug 2004 16:36:07 -0500 In-Reply-To: <87u0v6x41m.fsf@nwalsh.com> Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Norman Walsh writes: > What Dare said earlier in this thread: "Using dates as a versioning > mechanism seemed like a hack to me. I definitely oppose all efforts > to conflate the date issue with versioning." Please [re]read http://imc.org/atom-syntax/mail-archive/msg08423.html As far as I am aware no one is proposing using dates as a versioning mechanism, only as, as one use case, a mechanism to allow versioning to be added later as an extension without affecting Atom 1.0 processors. -- Ken From owner-atom-syntax@mail.imc.org Fri Aug 13 18:13:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21894 for ; Fri, 13 Aug 2004 18:13:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DM0lFr067567; Fri, 13 Aug 2004 15:00:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DM0lRm067565; Fri, 13 Aug 2004 15:00:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7DM0k4p067556 for ; Fri, 13 Aug 2004 15:00:46 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040813220046.93580.qmail@web41205.mail.yahoo.com> Received: from [131.107.76.139] by web41205.mail.yahoo.com via HTTP; Fri, 13 Aug 2004 15:00:46 PDT Date: Fri, 13 Aug 2004 15:00:46 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateSamRuby -1 To: Ken MacLeod , Atom Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ken MacLeod wrote: > > Please [re]read > http://imc.org/atom-syntax/mail-archive/msg08423.html > > As far as I am aware no one is proposing using dates > as a versioning > mechanism, only as, as one use case, a mechanism to > allow versioning > to be added later as an extension without affecting > Atom 1.0 > processors. Your mail implies that dates have something to do with versioning. I posit they don't and conflating the two is not a fruitful excercise. It seems you are not only assuming that Atom will have a mechanism for versioning entries in future but also what form this will take. I have first hand experience from various technologies that shows that assuming how a versioning model will evolve is often a difficult task to get right. Just ask the W3C XML Schema working group about xs:redefine ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Aug 13 20:44:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28498 for ; Fri, 13 Aug 2004 20:44:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E0Id4U077243; Fri, 13 Aug 2004 17:18:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7E0IdrR077242; Fri, 13 Aug 2004 17:18:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E0IcHf077233 for ; Fri, 13 Aug 2004 17:18:38 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.102]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BvmFt-000836-1A; Sat, 14 Aug 2004 00:18:41 +0000 Message-ID: <411D5A5B.2020009@franklinmint.fm> Date: Fri, 13 Aug 2004 20:18:35 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Ken MacLeod , Atom Syntax Subject: Re: PaceDateSamRuby -1 References: <20040813220046.93580.qmail@web41205.mail.yahoo.com> In-Reply-To: <20040813220046.93580.qmail@web41205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > --- Ken MacLeod wrote: > >>Please [re]read >> > > http://imc.org/atom-syntax/mail-archive/msg08423.html > >>As far as I am aware no one is proposing using dates >>as a versioning >>mechanism, only as, as one use case, a mechanism to >>allow versioning >>to be added later as an extension without affecting >>Atom 1.0 >>processors. > > > Your mail implies that dates have something to do with > versioning. I posit they don't and conflating the two > is not a fruitful excercise. It seems you are not only > assuming that Atom will have a mechanism for > versioning entries in future but also what form this > will take. > I agree with Dare here. Another possibility for a backwards-compatible versioning mechanism would be for atom:id to always point at the head revision (status quo). Versioning extensions would identify previous revisions with different URIs or point to a versioned resource. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 14 01:00:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09202 for ; Sat, 14 Aug 2004 01:00:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E4qSoE097175; Fri, 13 Aug 2004 21:52:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7E4qS5L097174; Fri, 13 Aug 2004 21:52:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E4qPMf097165 for ; Fri, 13 Aug 2004 21:52:26 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 14 Aug 2004 14:58:49 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 14 Aug 2004 14:52:17 +1000 Subject: Re: versioning or something simpler From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <87u0v6x41m.fsf@nwalsh.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14/8/04 4:53 AM, "Norman Walsh" wrote: > What Dare said earlier in this thread: "Using dates as a versioning > mechanism seemed like a hack to me. I definitely oppose all efforts to > conflate the date issue with versioning." Using dates for versioning is an 80/20 solution though. Is it really versioning that we're modelling though? Is it instead freshness that we are modelling, and isn't that what the market is really asking for more than a method of tracking distinct instances of a changing resource. If it is freshness of a changing resource which we are modelling, then using modified/updated dates is no longer an 80/20 solution, it's a 100% solution. e. From owner-atom-syntax@mail.imc.org Sat Aug 14 12:34:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21091 for ; Sat, 14 Aug 2004 12:34:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EGL2vu047718; Sat, 14 Aug 2004 09:21:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EGL2O2047717; Sat, 14 Aug 2004 09:21:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EGL10A047704 for ; Sat, 14 Aug 2004 09:21:01 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i7EGKu53016456 for ; Sat, 14 Aug 2004 11:20:56 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i7EGKtqP016452; Sat, 14 Aug 2004 11:20:55 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: Atom Syntax Subject: PaceDateKenMacLeod to be withdrawn References: <20040813220046.93580.qmail@web41205.mail.yahoo.com> From: Ken MacLeod Date: 14 Aug 2004 11:20:55 -0500 In-Reply-To: <20040813220046.93580.qmail@web41205.mail.yahoo.com> Message-ID: Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've seen only one possible message in support of PaceDateKenMacLeod (a date indicating last change of an entry) and several against, so I'm moving to withdraw it. However, I would like to resummarize the use cases for the change date. If anyone gets an, "oh, I didn't think of that" positive reaction, then say so, otherwise there is no need to reply. Note the second use case has not been mentioned previously. Use cases for atom:e: 1) When compared to a stored value of atom:e from a previous read, indicates (by being "later") whether any additional processing needs to be performed (such as overwriting the stored representation of the entry or further processing to determine whether the entry should be passed on or displayed). 2) If the same entry (same atom:id) is read from multiple sources (such as republishers) they may possibly differ, the value of atom:e indicates which is the latest. 3) If the same entry (same atom:id) appears more than once in the same feed, the value of atom:e is one indicator that can be used to determine which to process (store, pass on, or display). Another strong indicator would be xml:lang. atom:e serves the same purpose as the HTTP header Last-Modified. Best practice would be for publishing systems to ensure that the Last-Modified value of the entry on the server (any representation) is the value represented in atom:e. What happens in each case if atom:e is not adopted: 1) Assuming the source is authoritive (the original source), each new read of an entry can be considered the "latest" and be overwritten. Impact: minimal, unnecessary processing may occur. 2) This behavior is undefined. Impact: In the event that an entry differs between two or more sources (based on the time they retrieved the entry), there is then an equal or greater than 50% chance that silent data loss will occur. 3) This behavior is undefined, particularly it is also not defined as invalid in Atom format-01. Impact: Should this practice not be explicitly disallowed and a producer emits an entry more than once, there is then an equal to or greater than 50% chance that silent data loss will occur. Empirically, the chances of silent data loss approaches certainty, as most publishers put "new" entries towards the beginning of feeds and most consumers process entries in feed order so that later entries would overwrite earlier ones. -- Ken From owner-atom-syntax@mail.imc.org Sat Aug 14 13:35:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23422 for ; Sat, 14 Aug 2004 13:35:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EHOQBC051909; Sat, 14 Aug 2004 10:24:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EHOQ75051908; Sat, 14 Aug 2004 10:24:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EHOPI3051902 for ; Sat, 14 Aug 2004 10:24:25 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7EHQ7xc021901 for ; Sat, 14 Aug 2004 13:26:07 -0400 Message-ID: <411E4ACC.2050004@intertwingly.net> Date: Sat, 14 Aug 2004 13:24:28 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Accuracy and Precision in dates Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Contemplate, for a moment, realtime publishing. By that, I mean a world in which weblog entries are created, validated, made available, issued, modified, accepted, copyrighted, and submitted within seconds. On top of that, consider the constraints of a user polling once an hour or so. In such a system, knowing precisely in which point in in a thirty second process the date was assigned amounts to unnecessary precision. In physics class, many years ago, I learned the difference between accuracy and precision. Consistently hitting the target, it not the bullseye, was accuracy.[1] Consistently hitting the same place, even if that place was yards away from the target, is precision. The implication being that if you have a choice between accuracy and precision, accuracy is generally preferred. Now, let's look at pubDate in RSS 2.0. It very clearly specifies that this is to be the date that the entry was published. And that it is optional. Let's see how this applies to Blogger. When you create an entry, the time you are presented with an entry field, you are also presented with a time & date, which you can change. You can save it as draft and publish it later. The result is a date and time which is *not* the publish time. If you want to be pedantic, the right thing to do is to not provide a pubDate, but to define a new element which contains the proper semantics. That would be the precise thing to do. It would not increase interoperability, though. This is a case where the RSS 2.0 specification is unnecessarily precise. If interoperability is the goal, precisely specifying the radius and curvature of a round hole is not the best way to handle square pegs. Nor is the solution to define more round holes. Some of the Atom date proposals have had as many as five. The end result of such precision in the face of lack of consensus is that such portions of the spec will be routinely ignored. So, how does one increase accuracy? One way is to enumerate the interoperability issues. Dare's RSSBandit does not treat pubDate the same way as NetNewsWire does. Tim's usage of this element in RSS is consistent with the spec, and consistent with the way the tool of his choice implements this spec.[2] How does one resolve this interoperability issue? Simply to state that this value MAY change. Dare agrees.[3] Note that this is not a weak restriction[4] on producers, but effectively a warning to consumers. Other such warnings can increase the probability that the date indicated more often closely approximates when the entry became available than any other date. An extreme example to illustrate the point: The Diary of Samuel Pepys[5], republished in blog form 340 years later. How can we discourage the "first date of formal issuance" of these entries being placed into the atom:d element defined in PaceDateSamRuby? It would seem to me that a note that "Consumers MAY chose to sort based on this value." would discourage such usage. Similarly, how do we stop future dates? "Consumers MAY chose not to display entries containing atom:d elements until the date specified." seems like it would be a pretty effective deterrent. What have we lost? Well, if it turns out to be important that we capture precisely the formal, informative, dates associated with professional publications, it may make sense to indicate how such information be recorded in a consistent manner. I can think of nobody who has given that particular topic greater thought than the Dublin Core Metadata Initiative. They have conferences and workshops on the topic. That being said, I wouldn't have a problem with drawing a distinction between the definitions the DCMI have come with and the serialization syntax that the RSS-DEV Working Group came up for these terms. Perhaps it would make sense to standardize an RFC 3339 version of these dates. We can also discuss whether such dates should be in the core or in an extension. Another key element of a number of proposals is a modification or update date. We need to face the very distinct possibility that a number of producers will not distinguish between the two. In fact, some producers may not be able to consistently identify that a modification occurred at all, let alone when it occurred. Again, the solution (if this is deemed vital to be included in Atom 1.0) may be to identify the consequences of various usage patterns for this element. - Sam Ruby [1] http://elchem.kaist.ac.kr/vt/chem-ed/data/graphics/acc-prec.gif [2] http://www.imc.org/atom-syntax/mail-archive/msg07850.html [3] http://www.imc.org/atom-syntax/mail-archive/msg08419.html [4] http://www.imc.org/atom-syntax/mail-archive/msg08396.html [5] http://www.pepysdiary.com/ From owner-atom-syntax@mail.imc.org Sat Aug 14 16:12:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29882 for ; Sat, 14 Aug 2004 16:12:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EJr5aO061976; Sat, 14 Aug 2004 12:53:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7EJr52G061975; Sat, 14 Aug 2004 12:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7EJr5eK061952 for ; Sat, 14 Aug 2004 12:53:05 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <20040814195304013001824ge>; Sat, 14 Aug 2004 19:53:04 +0000 Date: Sat, 14 Aug 2004 13:52:58 -0600 Subject: Re: Accuracy and Precision in dates Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <411E4ACC.2050004@intertwingly.net> Message-Id: <8ACB8564-EE2B-11D8-8353-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, August 14, 2004, at 11:24 AM, Sam Ruby wrote: > In physics class, many years ago, I learned the difference between > accuracy and precision. Consistently hitting the target, it not the > bullseye, was accuracy.[1] Consistently hitting the same place, even > if that place was yards away from the target, is precision. The > implication being that if you have a choice between accuracy and > precision, accuracy is generally preferred. Here's my thinking on what Sam wrote: we need to decide 1) what the target(s) is/are that we want to hit, and 2) how to increase our accuracy in hitting that/those target(s). Here are some possible targets for use of date constructs, some of which may not be worth the trouble: 1) "Correct" or at least acceptable sort order (there are a number of possibilities for what a user might consider the best sort order) 2) Meaningful display date 3) Signaling that processing needs to be done ("something has changed since you saw this entry last") I think those are listed in order of importance, and that we can probably devise a better method for addressing #3 (for example, uri...). So how can we be the most accurate on #1, and can we also be accurate on #2? I don't think it's possible to do both with a single date construct. I'd imagine most users are usually going to want to sort based on either the initial publishing date, or the most recent significant update. There are likely also to be cases where people want to sort based on the "display date", though those would be more rare. Can we accommodate more than one of these, and how accurately? > So, how does one increase accuracy? One way is to enumerate the > interoperability issues. Dare's RSSBandit does not treat pubDate the > same way as NetNewsWire does. Tim's usage of this element in RSS is > consistent with the spec, and consistent with the way the tool of his > choice implements this spec.[2] > > How does one resolve this interoperability issue? Simply to state > that this value MAY change. Dare agrees.[3] Note that this is not a > weak restriction[4] on producers, but effectively a warning to > consumers. Okay, I see now how this is intended as a warning to consumers. I'll admit that I scanned the example in your proposal pretty quickly, and thus missed that point. I think making the point at least briefly before the example would be helpful. If a small number of implementers read specs, the number who read examples in specs carefully is going to be even smaller, so depending entirely on them to make important points is likely to lead to misunderstanding. > Other such warnings can increase the probability that the date > indicated more often closely approximates when the entry became > available than any other date. An extreme example to illustrate the > point: The Diary of Samuel Pepys[5], republished in blog form 340 > years later. How can we discourage the "first date of formal > issuance" of these entries being placed into the atom:d element > defined in PaceDateSamRuby? It would seem to me that a note that > "Consumers MAY chose to sort based on this value." would discourage > such usage. Explicitly providing a place to put a "display date" would be another, and would make the point more directly. If we DON'T provide a place for a display date, I'd like to see spec text more explicitly pointing out the implications of putting the "first date of formal issuance" there in such cases. > Similarly, how do we stop future dates? "Consumers MAY chose not to > display entries containing atom:d elements until the date specified." > seems like it would be a pretty effective deterrent. Again, a "display date" would be another possibility. > Another key element of a number of proposals is a modification or > update date. We need to face the very distinct possibility that a > number of producers will not distinguish between the two. In fact, > some producers may not be able to consistently identify that a > modification occurred at all, let alone when it occurred. Again, the > solution (if this is deemed vital to be included in Atom 1.0) may be > to identify the consequences of various usage patterns for this > element. There's definitely some distance between what is possible, at least with existing systems, and what is desirable. I'd say knowing the date of first issuance and the date of most recent "significant" update (where "significant" is subjectively determined by the publisher) and a "display date" (ie., a date associated with the content or meaning of the entry) would be desirable. That would enable all the methods of sorting I would expect to be most preferred, and the placing of an entry in temporal context by displaying a date associated with its content. However, getting all three dates is clearly not always possible. I have a difficult time letting go of the desire for a "display date", because if we don't support it explicitly, I can't think of a way to express it in a feed other than merging it into the content element--except by creating a new extension. But if the consensus is that we can drop it, I'll conceed. What would be the consequences of having a date with one meaning appear in a date construct spec'd for a date with a different meaning? For example, what if we have atom:updated (meaning the last "significatnt" update), but somebody puts the date of first issuance (of the ENTRY, not the entry's content) in it? Will that cause us problems in hitting our target (a good sort order) accurately? What if we have atom:issued (date of first issuance of the entry) and somebody puts the last significant update date in it? Would it be better to spec a date construct with an imprecise meaning ("it could be first issuance, last major change, last change of any kind, etc.") so that it is less likely to be "wrong"? I'm afraid that if we relax the meaning of the date construct too much, the value of processing it "correctly" will be diminished. I'd rather keep the definition somewhat tight to increase the probability that it's meaning will be consistent across feeds, and then accept that fact that some people aren't going to follow the spec perfectly. Without thinking too hard about the consequences, I don't think they'd be too terrible in most cases. I'd prefer to spec the date construct to indicate the last significant update. I'd think that would best accommodate: 1) Feeds that never get significant updates (they never have to change it) 2) Feeds that DO get significant updates (they CAN change it) 3) People who want to sort by the first issuance date (they can cache the first date they see in an entry, and ignore changes to it) 4) People who want to sort by the last significant update date (obviously) People who do make significant updates, but for whatever reason can't update the date wouldn't be perfectly served, but I'd say that's their own problem--if it causes too much pain, they can improve their publishing tool or move to a better one. People who can't provide any kind of "objective" date are going to cause reduced accuracy no matter what solution we pick, unless we loosen the spec to make the target difficult to miss. Since that would weaken the format for everyone else, I don't think we should go too far just to enable them to claim to be accurate and feel good about themselves. > [1] http://elchem.kaist.ac.kr/vt/chem-ed/data/graphics/acc-prec.gif > [2] http://www.imc.org/atom-syntax/mail-archive/msg07850.html > [3] http://www.imc.org/atom-syntax/mail-archive/msg08419.html > [4] http://www.imc.org/atom-syntax/mail-archive/msg08396.html > [5] http://www.pepysdiary.com/ From owner-atom-syntax@mail.imc.org Sat Aug 14 20:53:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10307 for ; Sat, 14 Aug 2004 20:53:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F0dlO6078261; Sat, 14 Aug 2004 17:39:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F0dlCa078260; Sat, 14 Aug 2004 17:39:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F0deko078242 for ; Sat, 14 Aug 2004 17:39:45 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 3A3217C124; Sun, 15 Aug 2004 03:31:59 +0200 (CEST) Date: Sun, 15 Aug 2004 02:41:09 +0200 To: "Eric Scheid" Subject: Re: dc:dates in atom - some questions Cc: Atom-Syntax References: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 13 Aug 2004 11:04:40 +1000, Eric Scheid wrote: > [1] Will the atom spec be providing text which describes what format the > dates will be in (eg. RFC 3339), and any other limitations or subset > definitions? I would like that, at least. > [2] Will this be valid in an atom feed: 1999-12-24 > and if so, how will the various aggregator developers > handle it? I don't know how aggregators will handle it, but that should be an allowed (though not preferred) date. I think we should encourage publishers do be as exact as possible in this regard, especially seeing that most of the DC dates should be provided (automatically) by tools. > [3] With dc:modified, will we be providing any clarification text, since > dc:modified is described with reference to terms of RSS. What do you mean with «since dc:modified is described with reference to terms of RSS»? In the DCMI document, 'modified' is described as «Date on which the resource was changed.»: > Will some publishers translate RSS terms to Atom terms, or will some > say "that's specific to RSS, Atom is different, so I'm ignoring that > bit of spec text"? Since Atom actually has a history (it effectively inherits RSS' history), we need to write something about it in the specification. If RSS' history and practice is unsuited for Atom, that needs to be mentioned. If RSS' history and practice is what we want in and from Atom, that needs to be mentioned as well. > If translating to Atom, is this the element which points to the > @rel="alternate" resource, or the resource which the entry is "about" > (eg. when pointing at an external resource, the original model for > RSS)? Wouldn't those be the same in most cases? Or am I misunderstanding something here? > [5] Should I be using dcterms:available or dcterms:issued, and which ones > will Shrook, RSS Bandit, NNW etc support or ignore? If the market by > practice decides on dcterms:issued (and mostly ignores dcterms:available, > thus resulting in aggregator clients ignoring same), should I stick my > value for dcterms:available in dcterms:issued just so I can provide > useful > functionality to my consumers? I don't know for sure. I'd guess that 'issued' would have the same value as the start-range of 'available' in most cases. What aggregators would do about this is uncertain, though. It would be nice to have some input from the DC people on what the practical difference between the start-range value of 'available' and 'issued' is. > [5] Does everyone realise that, apart from the issue of dcterms allowing > partial dates (eg. "2004-08"), some of the dc dates are not W3CDTF > values at all, but are instead date *ranges*? Since all Dublin Core dates are built on ISO 8601, I would assume the date ranges would still be proper ISO 8601 dates, only separated by a slash: 2004-08-14T00:00:00/2004-08-15T02:40:00 > [6] Look closely at that last date construct ... will we be supporting > the "scheme" sub-element, or mandating in the Atom spec that all dates > must be in RFC 3339 format? [and will the anti-micro-parser crowd please > chime in > now too?] I would like the scheme to be as strict as possible. That is, to encourage (but probably not enforce) as exact dates as possible. Ranges should be allowed though, which leaves W3CDTF and RFC 3339 out in uncertainty. Would it be too much to just write our own note on dates as a (non-) normative appendix, though? In that one, we could basically just copy W3CDTF, allow for the '-00:00' time zone designator from RFC 3339, and also date ranges as defined in ISO 8601. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 14 20:54:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10373 for ; Sat, 14 Aug 2004 20:54:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F0fjqE078356; Sat, 14 Aug 2004 17:41:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F0fjtK078355; Sat, 14 Aug 2004 17:41:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F0fiFY078345 for ; Sat, 14 Aug 2004 17:41:44 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 488197C124; Sun, 15 Aug 2004 03:34:22 +0200 (CEST) Date: Sun, 15 Aug 2004 02:43:34 +0200 To: "Antone Roundy" Subject: Re: dc:dates in atom - some questions Cc: Atom-Syntax References: <6563D963-ECC7-11D8-A471-003065EA6144@geckotribe.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <6563D963-ECC7-11D8-A471-003065EA6144@geckotribe.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 12 Aug 2004 19:23:35 -0600, Antone Roundy wrote: > If you want people to see your entry beginning at some particular time, > and available isn't widely supported, then wait till that time to > publish it rather than fudging the value of issued--that'd be my > preference. That would imho be the recommended practice nonetheless. Future dates just doesn't make much sense, especially if what the publisher wants is the entry not to appear until the specified date and time arrives. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 14 21:11:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10973 for ; Sat, 14 Aug 2004 21:11:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F0pt93079122; Sat, 14 Aug 2004 17:51:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F0ptVX079121; Sat, 14 Aug 2004 17:51:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F0ps1E079110 for ; Sat, 14 Aug 2004 17:51:55 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 055727C124; Sun, 15 Aug 2004 03:44:35 +0200 (CEST) To: "David Powell" Cc: Atom-Syntax Subject: Re: Using DC only for informational dates (was: Re: Date paces) References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> <1092397529.411ca9d96959e@webmail.djpowell.net> Message-ID: Date: Sun, 15 Aug 2004 02:53:48 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <1092397529.411ca9d96959e@webmail.djpowell.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 13 Aug 2004 12:45:29 +0100, David Powell wrote: > I'm not comfortable with specifying behaviours for DC dates, which I > believe are intended to be mostly informational. What's the use of these dates if no one is going to do anything with them, I wonder. I know I would like to do something with them, at least. Much more than I would ever want to do with any subjective date, at least. > If atom agents would be expected to associate behaviours with certain > dates then I'd rather those dates be inlined and fully specified by > Atom. That would be my preference anyway. I thought it was a goal to have Atom reference as few specifications, and inline as much (foreign) text, as possible. > Also I think that "display date" needs to be specified within Atom > because it isn't part of DC. True. Even 'dc:date' isn't appropriate as a highly subjective display date, since it's defined as «A date associated with an event in the life cycle of the resource» and «Typically, Date will be associated with the creation or availability of the resource». Neither of those sentences imply subjective, user-specified, only-for-display dates. But it's difficult to discuss these terms, as different people put different meanings in them all. > Well it does seem to exclude "display date" from the definition because > "display date" is a date associated with the content of the entry, not > necessarily with the publishing life-cycle. I agree. A subjective, user-provided date is imho, obviously not a part of the life-cycle of a resource. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 14 21:52:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12257 for ; Sat, 14 Aug 2004 21:52:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F1i2cC083008; Sat, 14 Aug 2004 18:44:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F1i28X083007; Sat, 14 Aug 2004 18:44:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-svc.ntlworld.com (mta08-svc.ntlworld.com [62.253.162.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F1hxjh082984 for ; Sat, 14 Aug 2004 18:44:01 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from cpc1-stke1-5-0-cust135.bagu.cable.ntl.com ([81.97.134.135]) by mta08-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040815014346.IWH27851.mta08-svc.ntlworld.com@cpc1-stke1-5-0-cust135.bagu.cable.ntl.com>; Sun, 15 Aug 2004 02:43:46 +0100 Date: Sun, 15 Aug 2004 02:44:00 +0100 From: David Powell X-Mailer: The Bat! (v2.13 "Lucky" Beta/5) Business Reply-To: David Powell X-Priority: 3 (Normal) Message-ID: <1021337343.20040815024400@djpowell.net> To: =?ISO-8859-1?B?QXNiavhybiBVbHNiZXJn?= CC: Atom-Syntax Subject: Re: Using DC only for informational dates (was: Re: Date paces) In-Reply-To: References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> <1092397529.411ca9d96959e@webmail.djpowell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sunday, August 15, 2004, 1:53:48 AM, asbjorn@tigerstaden.no wrote: > On Fri, 13 Aug 2004 12:45:29 +0100, David Powell > wrote: >> I'm not comfortable with specifying behaviours for DC dates, which I >> believe are intended to be mostly informational. > What's the use of these dates if no one is going to do anything with them, > I wonder. I know I would like to do something with them, at least. Much > more than I would ever want to do with any subjective date, at least. I probably wasn't very clear about what I mean by behaviours. I see Atom as a protocol for the transfer of metadata between agents. Some fields in atom:entry are part of the protocol, and some are part of the metadata/data. (The boundaries are a bit blurred though because all protocol fields are also metadata.) For example I'd class atom:id as part of the protocol - it is likely that Atom will specify behaviours of how the Atom protocol interacts with this field. I'd class atom:title to be part of the metadata. Atom has done its job if this field gets passed intact from the publisher to the client. The client of course can process this field in any way it chooses, but it is done outside of the Atom specification. (Perhaps we should be clearer in general about what the boundaries of Atom are, otherwise we are likely to over-specify user-agent behaviour and make intermediaries and automated "Atom services" difficult to implement within the specification.) An example of this principle in action would be dcterms:available. This field is used to describe when a document was/will be made available, but I believe that this field (like all of dcterms) should only be used as an informational field. Clients should not expect that setting a dcterms:available element to be in the future should hide that entry - if clients require future publishing then that would need to be specified as an extension using it's own namespace. (If I added to my website I wouldn't expect it to disappear). >> Also I think that "display date" needs to be specified within Atom >> because it isn't part of DC. > [...] > Neither of those sentences > imply subjective, user-specified, only-for-display dates. "Display date" is a bad name - I don't consider that date to be "only-for-display". I'd probably want to sort on it. In fact people might sort on absolutely any field. I think sort-order is out of scope of the spec. -- Dave From owner-atom-syntax@mail.imc.org Sun Aug 15 00:47:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18269 for ; Sun, 15 Aug 2004 00:47:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F4Qfgx093714; Sat, 14 Aug 2004 21:26:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F4Qfqg093713; Sat, 14 Aug 2004 21:26:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F4QdmS093703 for ; Sat, 14 Aug 2004 21:26:40 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 15 Aug 2004 14:33:12 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 15 Aug 2004 14:26:37 +1000 Subject: Re: dc:dates in atom - some questions From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7F4QfmS093707 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 15/8/04 10:43 AM, "Asbjørn Ulsberg" wrote: >> If you want people to see your entry beginning at some particular time, >> and available isn't widely supported, then wait till that time to >> publish it rather than fudging the value of issued--that'd be my >> preference. > > That would imho be the recommended practice nonetheless. Future dates just > doesn't make much sense, especially if what the publisher wants is the > entry not to appear until the specified date and time arrives. Use case: a conference is announced. it is of course occurring sometime in the future, no point announcing it otherwise. The announcement would be dated today(), but they make available a new feed for important information regarding the conference. One of those entries is a note about one of the speakers, who has deigned to make their slides available but only during the period the conference is on. The entry might look something like this: 2004-08-15T14:22+10:00 Joe Bob Joe Bob's slides name=The Big Conference; start=2002-09-05; end=2002-09-07; scheme=W3C-DTF Does that make sense? This way people know the slides will be available, and available for only a short window of time, and they can make plans to access and retrieve that resource. The conference organiser will also be alleviated of the endless emails that ask "when will the slides be available?". e. From owner-atom-syntax@mail.imc.org Sun Aug 15 00:48:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18312 for ; Sun, 15 Aug 2004 00:48:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F4Wwgc094027; Sat, 14 Aug 2004 21:32:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7F4Ww1U094026; Sat, 14 Aug 2004 21:32:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7F4WtN5094018 for ; Sat, 14 Aug 2004 21:32:56 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 15 Aug 2004 14:39:32 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 15 Aug 2004 14:32:57 +1000 Subject: Re: Using DC only for informational dates (was: Re: Date paces) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1021337343.20040815024400@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: Content-Transfer-Encoding: 7bit On 15/8/04 11:44 AM, "David Powell" wrote: > "Display date" is a bad name - I don't consider that date to be > "only-for-display". I'd probably want to sort on it. In fact people > might sort on absolutely any field. I sometimes sort by title for some feeds, and sometimes sort by category or by author on others. I might want to sort on other fields, but that's about all I get with my newsreader of choice. > I think sort-order is out of scope of the spec. +1 I've previously noted that while I consider as very important and useful to me, I wouldn't be sorting on it. I'd let the updated entry fall where it would normally sort, retaining context, and let my newsreader alert me to it's updated-ness some other way (eg. bolding the title). e. From owner-atom-syntax@mail.imc.org Sun Aug 15 11:11:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02899 for ; Sun, 15 Aug 2004 11:11:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FEuCp6044661; Sun, 15 Aug 2004 07:56:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FEuCcp044660; Sun, 15 Aug 2004 07:56:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FEu9FA044640 for ; Sun, 15 Aug 2004 07:56:09 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 33880 invoked by uid 17064); 15 Aug 2004 14:56:05 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.131.147]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 15 Aug 2004 14:56:05 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <37EA4202-EECB-11D8-A370-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom Syntax , rdfweb-dev@vapours.rdfweb.org, bloged From: Henry Story Subject: Atom-FOAF Date: Sun, 15 Aug 2004 16:55:59 +0200 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have written out a full description with a lot of illustrations on how to FOAFify Atom [1]. The description is written out as a blog which is using the format it is advocating to back it up. So it is both a description and a proof of concept. I see this being useful to the foaf, atom, and bloged communities for different reasons: - for the atom community it could bring bring some ontological insight, and lead to clarifications - mapping always do that. - for the foaf community, I suggest this as an opening into the blogging space - for bloged, the blog editor I am working on, this will be useful at the very least to help nail down the needed data structures, though I hope to use it both as an internal and external data-structure. I look very much forward to any criticism. This document is the result of many such criticisms, for which I am very thankful. Henry Story [1] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html From owner-atom-syntax@mail.imc.org Sun Aug 15 11:51:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05375 for ; Sun, 15 Aug 2004 11:51:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FFERSH046276; Sun, 15 Aug 2004 08:14:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FFER7d046275; Sun, 15 Aug 2004 08:14:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FFEQrx046268 for ; Sun, 15 Aug 2004 08:14:26 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 10186 invoked from network); 15 Aug 2004 15:14:27 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Aug 2004 15:14:26 -0000 Message-ID: <09ee01c482da$8e068590$200ca8c0@wkearney.com> From: "Bill Kearney" To: References: <6563D963-ECC7-11D8-A471-003065EA6144@geckotribe.com> Subject: Re: dc:dates in atom - some questions Date: Sun, 15 Aug 2004 11:14:26 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > If you want people to see your entry beginning at some particular time, > > and available isn't widely supported, then wait till that time to > > publish it rather than fudging the value of issued--that'd be my > > preference. > > That would imho be the recommended practice nonetheless. Future dates just > doesn't make much sense, especially if what the publisher wants is the > entry not to appear until the specified date and time arrives. Or use a format better suited for it. At the present time NewML, with all of its syntactic complexities, is probably a better choice. If and it's a BIG IF, the market evolves such that considerable consumer demand exists for such things there's always room for further evolution of the standard(s) involved. -Bill Kearney Syndic8 From owner-atom-syntax@mail.imc.org Sun Aug 15 11:59:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05769 for ; Sun, 15 Aug 2004 11:59:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FFhccn048781; Sun, 15 Aug 2004 08:43:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FFhcHU048780; Sun, 15 Aug 2004 08:43:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FFhbBp048772 for ; Sun, 15 Aug 2004 08:43:37 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7FFj8RY027151; Sun, 15 Aug 2004 11:45:13 -0400 Message-ID: <411F84A0.3010200@intertwingly.net> Date: Sun, 15 Aug 2004 11:43:28 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Atom Syntax , rdfweb-dev@vapours.rdfweb.org, bloged Subject: Re: Atom-FOAF References: <37EA4202-EECB-11D8-A370-000A95D9FA7A@bblfish.net> In-Reply-To: <37EA4202-EECB-11D8-A370-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > > I have written out a full description with a lot of illustrations on how > to FOAFify Atom [1]. The description is written out as a blog which is > using the format it is advocating to back it up. So it is both a > description and a proof of concept. [snip] > I look very much forward to any criticism. This document is the result > of many such criticisms, for which I am very thankful. > > Henry Story > > [1] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html I have a few questions, let's take as an example. 1) Why does line 13 have "^^xsd:string", but neither line 18 nor line 26 do? 2) Why is :data an declared as "^^rdf:XMLLiteral"? 3) Why does :created have " GMT" in it? I believe this makes it an invalid xsd:dateTime value. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 15 13:29:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09228 for ; Sun, 15 Aug 2004 13:29:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FHIfOG056361; Sun, 15 Aug 2004 10:18:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FHIfxs056360; Sun, 15 Aug 2004 10:18:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FHIfMd056352 for ; Sun, 15 Aug 2004 10:18:41 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 32191 invoked by uid 17064); 15 Aug 2004 17:18:44 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.131.147]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 15 Aug 2004 17:18:44 -0000 In-Reply-To: <411F84A0.3010200@intertwingly.net> References: <37EA4202-EECB-11D8-A370-000A95D9FA7A@bblfish.net> <411F84A0.3010200@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <25E46D04-EEDF-11D8-A370-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , rdfweb-dev@vapours.rdfweb.org From: Henry Story Subject: Re: Atom-FOAF Date: Sun, 15 Aug 2004 19:18:38 +0200 To: Sam Ruby X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15 Aug 2004, at 17:43, Sam Ruby wrote: > > Henry Story wrote: >> I have written out a full description with a lot of illustrations on >> how to FOAFify Atom [1]. The description is written out as a blog >> which is using the format it is advocating to back it up. So it is >> both a description and a proof of concept. > > [snip] > >> I look very much forward to any criticism. This document is the >> result of many such criticisms, for which I am very thankful. >> Henry Story >> [1] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html > > I have a few questions, let's take > > as an example. The short answer to all your questions, is because nobody has yet looked at this as closely as you have :-) > > 1) Why does line 13 have "^^xsd:string", but neither line 18 nor line > 26 > do? I have changed all of them to ^^xsd:string. I am using Jena so that just required me to change my code to model.createTypedLiteral(mime) > 2) Why is :data an declared as "^^rdf:XMLLiteral"? I thought that since the value of the data field of a content object would most likely be xml, this would probably be the best type to give it. But I am fully open to criticism here. > 3) Why does :created have " GMT" in it? I believe this makes it an > invalid xsd:dateTime value. That's because I must have copied and pasted my Java date creation time from a flawed source. I have now changed it to: df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss"); //ISO 8601 format If there is a better format string for java please let me know. > > - Sam Ruby These changes are now on the web site. Thanks for the comments. I hope my fixes are moving me in the right direction. Henry From owner-atom-syntax@mail.imc.org Sun Aug 15 14:03:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10708 for ; Sun, 15 Aug 2004 14:03:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FHqt3S059293; Sun, 15 Aug 2004 10:52:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FHqtLZ059292; Sun, 15 Aug 2004 10:52:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FHqrkJ059280 for ; Sun, 15 Aug 2004 10:52:55 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BwPBZ-0005X9-2o for atom-syntax@imc.org; Sun, 15 Aug 2004 17:52:49 +0000 Message-ID: <411FA2F4.2080402@franklinmint.fm> Date: Sun, 15 Aug 2004 13:52:52 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: atom:id as variable assignment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've made an effort to document the various models for atom:id I've seen on the list. 1.) Immutable 2.) Immutable/Composable (all entries are append-only collections) 3.) Mutable (current practice) 4.) Mutable w/ collection membership I'm in favor of 3 & 4, and I've attempted to show that they don't preclude versioning capabilities. ------------------------------------------------------------------------ 1.) atom:id as identifier for immutable Atom Entries. Changes to the atom:entry require generation of a new identifier. myid = foo [update the entry] myid2 = bar The problem with this approach is that consumers are likely to receive mostly duplicated content under different ids, something no one is interested in. 2.) A variation on identifiers and immutable values composes atom:id as a sort of A-list. Some proposals along these lines use composable URI parts (e.g. NewsML IDs). Others have proposed using atom:id in combination with a Date element. The first part of the atom:id can be considered the "entry collection", consisting of the states the entry has held. As the state is changed, a value is appended to the collection. The second part of the id is the "key" that identifies a specific incarnation of the entry. Each member of the collection is immutable. my[id] = foo my = { id:foo } my[id2] = bar my = { id:foo, id2:bar } Thus, an entry would always be a collection type, even though most entries would consist only one member (and perhaps an implicit null key or index). One can imagine a scenario where an author decides to include full-content in his/her feed and also to retroactively apply this change. This would require versioned storage and transform all entries into multi-member collections. Is this a burden we wish to mandate? Note that the burden is social as well as technical, since it requires authors to highlight edits in a machine readable manner. Existing practice has placed the burden of versioned storage on consumers. 3.) Atom ID as identifier for a mutable variable. The identifier may be mapped to a changed atom:entry (the value is mutable/assignable). This closely matches current practice. myid = foo [update the entry] myid = bar The issue here is that no method of indicating a change has been agreed upon. There have been proposals suggesting a timestamp for this purpose. From a consumer's perspective, there exists the possibility of lost updates, since a timestamp may be updated more than once during a given polling interval. 4.) Allow atom:entry values to remain mutable, but allow the presence of link relations to indicate grouping. A possibility here would be a link relation (extension or core) that signals the location of the old content of the entry. That is, the atom:id served in the feed always points to the newest value of the entry. Historical values may be retrieved or identified by other URIs. myid = foo [update the entry] myid = bar This is probably the best way forward, since it's compatible with all existing clients, while preserving the possibility of versioned updates for those publishers or clients that require this capability. This link could point to a retrievable resource with versioning capabilities, such as WebDAV/DeltaV. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Aug 15 15:30:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15524 for ; Sun, 15 Aug 2004 15:30:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FJH5id064893; Sun, 15 Aug 2004 12:17:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FJH5gb064892; Sun, 15 Aug 2004 12:17:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FJH5vm064879; Sun, 15 Aug 2004 12:17:05 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BwQV6-00009Q-NU; Sun, 15 Aug 2004 19:17:04 +0000 Message-ID: <411FB6B4.3050504@franklinmint.fm> Date: Sun, 15 Aug 2004 15:17:08 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax , phoffman@imc.org Subject: id moratorium (was: atom:id as variable assignment) References: <411FA2F4.2080402@franklinmint.fm> In-Reply-To: <411FA2F4.2080402@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > I've made an effort to document the various models for atom:id I've seen > on the list ...which you should ignore because this topic is under moratorium. I forgot. Sorry! Robert Sayre From owner-atom-syntax@mail.imc.org Sun Aug 15 16:51:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18949 for ; Sun, 15 Aug 2004 16:51:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FKRHZZ070068; Sun, 15 Aug 2004 13:27:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FKRHKH070067; Sun, 15 Aug 2004 13:27:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FKRGPf070056 for ; Sun, 15 Aug 2004 13:27:16 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7FKSvhg008214; Sun, 15 Aug 2004 16:28:57 -0400 Message-ID: <411FC721.4090801@intertwingly.net> Date: Sun, 15 Aug 2004 16:27:13 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Atom Syntax , rdfweb-dev@vapours.rdfweb.org Subject: Re: Atom-FOAF References: <37EA4202-EECB-11D8-A370-000A95D9FA7A@bblfish.net> <411F84A0.3010200@intertwingly.net> <25E46D04-EEDF-11D8-A370-000A95D9FA7A@bblfish.net> In-Reply-To: <25E46D04-EEDF-11D8-A370-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: >> 2) Why is :data an declared as "^^rdf:XMLLiteral"? > > I thought that since the value of the data field of a content object > would most likely be xml, this would probably be the best type to give > it. But I am fully open to criticism here. In general, text/html is a xsd:string. application/xhtml+xml is xml. >> 3) Why does :created have " GMT" in it? I believe this makes it an >> invalid xsd:dateTime value. > > That's because I must have copied and pasted my Java date creation time > from a flawed source. > > I have now changed it to: > df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss"); //ISO 8601 format Other than four extra characters being present in your original source (" GMT"), the previous version was preferred as it included a timezone offset. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 15 18:39:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25021 for ; Sun, 15 Aug 2004 18:39:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FML1it078490; Sun, 15 Aug 2004 15:21:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FML1WI078489; Sun, 15 Aug 2004 15:21:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FML13g078478 for ; Sun, 15 Aug 2004 15:21:01 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 2F2BB727D for ; Sun, 15 Aug 2004 15:21:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Shipping Atom products prematurely Date: Sun, 15 Aug 2004 15:21:00 -0700 To: Atom WG X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've just changed the old, pre-WG drafts that I host on mnot.net to clearly state that they're not to be implemented, and are superseded by the work here. One of the things that drove me to do this is the increasing incidence of vendors shipping products and services that "support" Atom, even though it's clearly marked as a pre-draft (on my site) and only for experimental implementation (in the WG's drafts). Working on experimental Atom implementations is great because it helps us get experience and find problems. However, shipping it in mass-market products before it's done is likely to lead to a lot of interoperability problems, end-user support issues and even barriers to adoption as the spec matures. As such, I think the WG should proactively contact vendors of consumer products and services and ask them to refrain from integrating Atom support until it's done. They have the best of intentions by supporting Atom, but may do more harm than good by accelerating the adoption of it prematurely. I'm not naming names here, but I have two vendors in particular in mind. I *don't* mean the smaller aggregator-only vendors or personal blogs who have made a choice to experimentally support Atom; I mean those that are pushing Atom to an audience who doesn't understand what the issues are. Thoughts? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sun Aug 15 19:23:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26613 for ; Sun, 15 Aug 2004 19:23:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FNGE9L084059; Sun, 15 Aug 2004 16:16:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FNGE9m084058; Sun, 15 Aug 2004 16:16:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FNGD63084051 for ; Sun, 15 Aug 2004 16:16:13 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 10224 invoked from network); 15 Aug 2004 23:16:16 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Aug 2004 23:16:16 -0000 Message-ID: <0be201c4831d$dd4feef0$200ca8c0@wkearney.com> From: "Bill Kearney" To: "Atom WG" References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> Subject: Re: Shipping Atom products prematurely Date: Sun, 15 Aug 2004 19:16:15 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I'm not naming names here, but I have two vendors in particular in > mind. I *don't* mean the smaller aggregator-only vendors or personal > blogs who have made a choice to experimentally support Atom; I mean > those that are pushing Atom to an audience who doesn't understand what > the issues are. Yes, from a syndication format I've found it HIGHLY premature for use of Atom. It's a great thing and when it's offered in parallel with mature standards like RSS-1.0 it's a great thing. But to offer it as the SOLE syndication format /at this time/ is a less-than-idea situation. This implies nothing about any one format being any better or worse than another. Now, if the choice is 'atom or nothing' then I'm certainly willing to support use of it. I'd rightly complain about the surge of naive developers we'll have to put up with as legacy nightmares because of it. This, however, is considerably less worse than putting up with feeding that nitwit ego sure to crow about RSS... I'm not sure how I'd feel about it from a client/server editing perspective. There are some disjoint issues between what the hosting environments "need" and what some folks are insisting upon grafting into atom. This is, perhaps, a much stickier issue but one that might easily be resolved by establishing compliance profiles with perhaps some timeframe expectations. -Bill Kearney Syndic8.com From owner-atom-syntax@mail.imc.org Sun Aug 15 20:34:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29027 for ; Sun, 15 Aug 2004 20:34:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G0MLmC089004; Sun, 15 Aug 2004 17:22:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7G0MLqY089003; Sun, 15 Aug 2004 17:22:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G0MLs3088997 for ; Sun, 15 Aug 2004 17:22:21 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 32419 invoked by uid 17064); 16 Aug 2004 00:22:26 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.129.99]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 16 Aug 2004 00:22:26 -0000 In-Reply-To: <411FC721.4090801@intertwingly.net> References: <37EA4202-EECB-11D8-A370-000A95D9FA7A@bblfish.net> <411F84A0.3010200@intertwingly.net> <25E46D04-EEDF-11D8-A370-000A95D9FA7A@bblfish.net> <411FC721.4090801@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <569080BC-EF1A-11D8-A04F-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , rdfweb-dev@vapours.rdfweb.org, bloged From: Henry Story Subject: Re: Atom-FOAF Date: Mon, 16 Aug 2004 02:22:20 +0200 To: Sam Ruby X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have now fixed these two further bugs. Thanks for the feedback. Still looking forward to more of the same medicine :-) Henry On 15 Aug 2004, at 22:27, Sam Ruby wrote: > Henry Story wrote: > >>> 2) Why is :data an declared as "^^rdf:XMLLiteral"? >> I thought that since the value of the data field of a content object >> would most likely be xml, this would probably be the best type to >> give it. But I am fully open to criticism here. > > In general, text/html is a xsd:string. application/xhtml+xml is xml. I would like at a later stage to rewrite my blog in xhtml. But for the moment it is in html, so I'll use xsd:string. I suppose that if one uses application/xhtml+xml and one wants to insert xml fragments, these always have to be wrapped in a top level tag such as

...
I need to fix the OWL file to make the data field be either xsd:string or rdf:XMLLiteral. Currently this is not possible to do in Protege, so I'll wait for a point when I am confident enough to write OWL files by hand to add that. > >>> 3) Why does :created have " GMT" in it? I believe this makes it an >>> invalid xsd:dateTime value. >> That's because I must have copied and pasted my Java date creation >> time from a flawed source. >> I have now changed it to: >> df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss"); //ISO 8601 >> format > > Other than four extra characters being present in your original source > (" GMT"), the previous version was preferred as it included a timezone > offset. > > - Sam Ruby > From owner-atom-syntax@mail.imc.org Sun Aug 15 20:46:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29522 for ; Sun, 15 Aug 2004 20:46:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G0PfF8089278; Sun, 15 Aug 2004 17:25:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7G0Pfnb089275; Sun, 15 Aug 2004 17:25:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7G0Peww089250 for ; Sun, 15 Aug 2004 17:25:40 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 10088 messnum 5113209 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 16 Aug 2004 00:25:36 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail04.svc.cra.dublin.eircom.net (qp 10088) with SMTP; 16 Aug 2004 00:25:36 -0000 Message-ID: <411FFEFE.6060602@dehora.net> Date: Mon, 16 Aug 2004 01:25:34 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom WG Subject: Re: Shipping Atom products prematurely References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> In-Reply-To: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@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: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > Thoughts? I mostly agree. Tho' in one way, stopping people shipping - well as problems go there's worse. Also, a) we should start setting expectations as to when this thing will ship. I have people asking me and the answer I give is I don't know, but I know I'm not confident about 2004. b) the chairs (and maybe the editors) need to continue to be aggressive about controlling discussion on this forum. Yes of course, consensus good, two legs bad, but if Hoffman or Bray say to stfu, please continue to do it. c) churn the specs more frequently. Currently we have a July 15 draft that expires next January (that's too many dog years imho) And personally I'd rather be tracking spec text than wiki pages at this stage. d) the [[ ]] style callouts need to be laced with !!!, ###, @@@ or ??? marks - that looks more hacked up, unfinished and dangerous to the eye. It's a little thing, but you guys are far too neat. Observation: I'm currently finding the optimal contribution I can make is to not post as much. cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 15 22:35:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15570 for ; Sun, 15 Aug 2004 22:35:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G2JgXv000757; Sun, 15 Aug 2004 19:19:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7G2JgBn000756; Sun, 15 Aug 2004 19:19:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7G2JgEf000722 for ; Sun, 15 Aug 2004 19:19:42 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040816021941.34808.qmail@web41212.mail.yahoo.com> Received: from [64.136.27.225] by web41212.mail.yahoo.com via HTTP; Sun, 15 Aug 2004 19:19:41 PDT Date: Sun, 15 Aug 2004 19:19:41 -0700 (PDT) From: Dare Obasanjo Subject: Re: Shipping Atom products prematurely To: Mark Nottingham , Atom WG In-Reply-To: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Mark Nottingham wrote: > > I've just changed the old, pre-WG drafts that I host > on mnot.net to > clearly state that they're not to be implemented, > and are superseded by > the work here. > > One of the things that drove me to do this is the > increasing incidence > of vendors shipping products and services that > "support" Atom, even > though it's clearly marked as a pre-draft (on my > site) and only for > experimental implementation (in the WG's drafts). I know what you mean. I pinged a contact of one of the vendors whose support of Atom was all over the news of what they plan to do when Atom becomes final since I'm worried about what could happen to the thousands of RSS Bandit users that could be shafted if they switch Atom versions. The response I got was basically 'Marketing will figure it out', I would have pressed the point but Sam [Ruby] was on the email thread and he claimed that such a discussion wasn't fruitful or something similar so I let it go. > Working on experimental Atom implementations is > great because it helps > us get experience and find problems. However, > shipping it in > mass-market products before it's done is likely to > lead to a lot of > interoperability problems, end-user support issues > and even barriers to > adoption as the spec matures. > > As such, I think the WG should proactively contact > vendors of consumer > products and services and ask them to refrain from > integrating Atom > support until it's done. They have the best of > intentions by supporting > Atom, but may do more harm than good by accelerating > the adoption of it > prematurely. I'm not sure what you expect to happen here. For those that have already deployed draft verions of Atom the horse has already left the barn. The best the WG can do is find out what they plan to do in future when newer drafts show up or the specs become final. For those that haven't deployed the drafts unless you have access to the precrime unit from Minority Report there isn't anyway to contact them and tell them not to do it. :) > I'm not naming names here, but I have two vendors in > particular in > mind. I *don't* mean the smaller aggregator-only > vendors or personal > blogs who have made a choice to experimentally > support Atom; I mean > those that are pushing Atom to an audience who > doesn't understand what > the issues are. Never ascribe to malice that which can be explained by incompetence[0] [0] http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=49b611e5-3788-4921-8b55-00fc08de7e9e ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sun Aug 15 23:13:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18079 for ; Sun, 15 Aug 2004 23:13:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G321vs004550; Sun, 15 Aug 2004 20:02:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7G321jj004549; Sun, 15 Aug 2004 20:02:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G320mY004530 for ; Sun, 15 Aug 2004 20:02:00 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id C953B727D; Sun, 15 Aug 2004 20:02:06 -0700 (PDT) In-Reply-To: <20040816021941.34808.qmail@web41212.mail.yahoo.com> References: <20040816021941.34808.qmail@web41212.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Shipping Atom products prematurely Date: Sun, 15 Aug 2004 20:02:05 -0700 To: Dare Obasanjo X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 15, 2004, at 7:19 PM, Dare Obasanjo wrote: > I'm not sure what you expect to happen here. For those > that have already deployed draft verions of Atom the > horse has already left the barn. The best the WG can > do is find out what they plan to do in future when > newer drafts show up or the specs become final. I'm specifically thinking of very large vendors who have announced support for Atom in upcoming products and IIRC have seeded developer betas, and those who have made Atom feeds the preferred method of syndication for large-scale Blog hosting betas. Remember that the deployment footprint of Atom is still relatively small, especially on the consumer side; if we don't check this, it will be very large, and people will start arguing "we can't change feature X in the draft because vendor Y has already shipped n million units that depend upon it." -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 16 01:12:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24091 for ; Mon, 16 Aug 2004 01:12:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G4qkrv014002; Sun, 15 Aug 2004 21:52:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7G4qklO014001; Sun, 15 Aug 2004 21:52:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7G4qjSk013992 for ; Sun, 15 Aug 2004 21:52:45 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7G4qnuo007351; Mon, 16 Aug 2004 00:52:50 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BND62722 (AUTH bob@wyman.us); Mon, 16 Aug 2004 00:52:49 -0400 (EDT) Message-Id: <200408160452.BND62722@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" , "'Atom-Syntax'" Subject: RE: Accuracy and Precision in dates Date: Mon, 16 Aug 2004 00:53:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSCJan0EF1U3jbsS7qHF50MWf3TegBJZOGA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-reply-to: <411E4ACC.2050004@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Contemplate, for a moment, realtime publishing. ... > consider the constraints of a user polling once an hour > or so. In such a system, knowing precisely in which point in a > thirty second process the date was assigned amounts to unnecessary > precision. Realtime publishing[1] is what you get from PubSub.com if you use our XMPP based service[2] and you are writing to a blog that pings us. The time delay between when you publish an entry and when we deliver it to subscribers can be on the order of just a few seconds... We should not be using the old-style RSS polling model as the basis for designing fundamental components of the Atom format or protocol. If anything, we should be assuming that publishing will be instantaneous -- the format should work well even if publishing is orders of magnitude faster than anything we have today. Let's not design in the constraints of old technology... bob wyman [1] Or, "near realtime" in order to keep the "realtime" purists happy... [2] http://pubsub.com/developers.php, Note: Soon, we'll be announcing other news aggregators that provide support for XMPP delivery of Atom entries in near realtime. From owner-atom-syntax@mail.imc.org Mon Aug 16 11:21:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10718 for ; Mon, 16 Aug 2004 11:21:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GF7qDj049321; Mon, 16 Aug 2004 08:07:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GF7q3M049320; Mon, 16 Aug 2004 08:07:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41201.mail.yahoo.com (web41201.mail.yahoo.com [66.218.93.34]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7GF7pOH049292 for ; Mon, 16 Aug 2004 08:07:51 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040816150749.77472.qmail@web41201.mail.yahoo.com> Received: from [64.136.27.225] by web41201.mail.yahoo.com via HTTP; Mon, 16 Aug 2004 08:07:49 PDT Date: Mon, 16 Aug 2004 08:07:49 -0700 (PDT) From: Dare Obasanjo Subject: Re: Shipping Atom products prematurely To: Mark Nottingham Cc: Atom WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Mark Nottingham wrote: > > I'm specifically thinking of very large vendors who > have announced > support for Atom in upcoming products and IIRC have > seeded developer > betas, and those who have made Atom feeds the > preferred method of > syndication for large-scale Blog hosting betas. > > Remember that the deployment footprint of Atom is > still relatively > small, especially on the consumer side; if we don't > check this, it will > be very large, and people will start arguing "we > can't change feature X > in the draft because vendor Y has already shipped n > million units that > depend upon it." I understand that but what do you want them to do? Stop deploying the Atom syndication format and Atom API and revert to RSS & Blogger API/MetaWeblog API/etc? Freeze deployment of Atom at whatever drafts they are currently using then upgrade when v1.0 ships? Or something else. Simply telling them "I don't like that you are doing" without providing an alternative is one way to ensure that your opinion is ignored. What is the alternative that you think the WG should suggest to these vendors? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Mon Aug 16 11:36:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11458 for ; Mon, 16 Aug 2004 11:36:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GFM4Pf053348; Mon, 16 Aug 2004 08:22:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GFM4Kt053347; Mon, 16 Aug 2004 08:22:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GFM4WK053338 for ; Mon, 16 Aug 2004 08:22:04 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id CCA88727D; Mon, 16 Aug 2004 08:22:06 -0700 (PDT) In-Reply-To: <20040816150749.77472.qmail@web41201.mail.yahoo.com> References: <20040816150749.77472.qmail@web41201.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <08950A9B-EF98-11D8-9BC6-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Shipping Atom products prematurely Date: Mon, 16 Aug 2004 08:22:06 -0700 To: Dare Obasanjo X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ah; I misunderstood your question. My suggestion would be to not ship Atom in mass-market products until it's done (or at least close to being done). RSS is already out there. Of course, this stance puts enormous pressure on the WG to get done quickly, but I have no problem with that... On Aug 16, 2004, at 8:07 AM, Dare Obasanjo wrote: > > --- Mark Nottingham wrote: > >> >> I'm specifically thinking of very large vendors who >> have announced >> support for Atom in upcoming products and IIRC have >> seeded developer >> betas, and those who have made Atom feeds the >> preferred method of >> syndication for large-scale Blog hosting betas. >> >> Remember that the deployment footprint of Atom is >> still relatively >> small, especially on the consumer side; if we don't >> check this, it will >> be very large, and people will start arguing "we >> can't change feature X >> in the draft because vendor Y has already shipped n >> million units that >> depend upon it." > > I understand that but what do you want them to do? > Stop deploying the Atom syndication format and Atom > API and revert to RSS & Blogger API/MetaWeblog > API/etc? Freeze deployment of Atom at whatever drafts > they are currently using then upgrade when v1.0 ships? > Or something else. > > Simply telling them "I don't like that you are doing" > without providing an alternative is one way to ensure > that your opinion is ignored. What is the alternative > that you think the WG should suggest to these vendors? > > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 > No matter how well it would perform, I will never construct any sort > of machinery which is completely indestructible except for one small > and virtually inaccessible vulnerable spot. > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 16 12:05:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13034 for ; Mon, 16 Aug 2004 12:05:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GFpbXu062676; Mon, 16 Aug 2004 08:51:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GFpb5v062675; Mon, 16 Aug 2004 08:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GFpbRk062639 for ; Mon, 16 Aug 2004 08:51:37 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc12) with SMTP id <2004081615513401400lci54e>; Mon, 16 Aug 2004 15:51:35 +0000 Date: Mon, 16 Aug 2004 09:51:33 -0600 Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <08950A9B-EF98-11D8-9BC6-000A95BD86C0@mnot.net> Message-Id: <25DEA200-EF9C-11D8-9AF1-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, August 16, 2004, at 09:22 AM, Mark Nottingham wrote: > Ah; I misunderstood your question. My suggestion would be to not ship > Atom in mass-market products until it's done (or at least close to > being done). RSS is already out there. > I would think that we'd like to recommend not shipping Atom in mass-market PUBLISHING tools till it's done, but off the top of my head, I don't see any problem with shipping it in CONSUMING tools. Am I missing something? From owner-atom-syntax@mail.imc.org Mon Aug 16 12:33:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14236 for ; Mon, 16 Aug 2004 12:33:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GGJJkL069436; Mon, 16 Aug 2004 09:19:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GGJJfF069434; Mon, 16 Aug 2004 09:19:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GGJI0n069412 for ; Mon, 16 Aug 2004 09:19:18 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA03946 for ; Mon, 16 Aug 2004 09:19:14 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA17527 for ; Mon, 16 Aug 2004 09:19:14 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 16 Aug 2004 09:19:14 -0700 Received: from adsl-64-166-133-244.dsl.snfc21.pacbell.net (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2J00INARZZT1@shazam.verity.com> for atom-syntax@imc.org; Mon, 16 Aug 2004 09:19:13 -0700 (PDT) Date: Mon, 16 Aug 2004 09:19:11 -0700 From: Walter Underwood X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy Subject: Re: Shipping Atom products prematurely In-reply-to: <20040816150749.77472.qmail@web41201.mail.yahoo.com> To: Atom WG Message-id: <27A5D10FC0682055F6F90277@adsl-64-166-133-244.dsl.snfc21.pacbell.net> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <20040816150749.77472.qmail@web41201.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT --On Monday, August 16, 2004 8:07 AM -0700 Dare Obasanjo wrote: > > I understand that but what do you want them to do? > Stop deploying the Atom syndication format and Atom > API and revert to RSS & Blogger API/MetaWeblog > API/etc? Use time-limited beta releases. If the product implements a draft Atom spec, then it is a beta. The product should time out when the draft does, or earlier. The click wrap and release notes should make it clear that the Atom implementation is experimental. There is no practical way to support an implementation of a protocol draft. The protocol spec may change in incompatible ways, where it is really difficult to distinguish between the two. Without support, how can it be a product? As a commercial product, you could get in trouble with your accountants for recognizing support revenue for something you can't support. Yes, post-bubble accountants pay attention to that. And please just name companies instead of saying "an unnamed large vendor". If they've made a public statement, there is nothing to gain by being obscure. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Aug 16 12:34:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14270 for ; Mon, 16 Aug 2004 12:34:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GGP5sJ070702; Mon, 16 Aug 2004 09:25:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GGP5Pn070701; Mon, 16 Aug 2004 09:25:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GGP23F070688; Mon, 16 Aug 2004 09:25:03 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <411FB6B4.3050504@franklinmint.fm> References: <411FA2F4.2080402@franklinmint.fm> <411FB6B4.3050504@franklinmint.fm> Date: Mon, 16 Aug 2004 09:10:56 -0700 To: Robert Sayre From: Paul Hoffman / IMC Subject: Re: id moratorium (was: atom:id as variable assignment) Cc: Atom Syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:17 PM -0400 8/15/04, Robert Sayre wrote: >Robert Sayre wrote: > >> >>I've made an effort to document the various models for atom:id I've >>seen on the list > >...which you should ignore because this topic is under moratorium. > >I forgot. Sorry! Thank you for noticing. :-) The topic is important (and festering), so Tim and I will try to come up with a reasonable way of getting the discussion going again this week. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Aug 16 19:09:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19754 for ; Mon, 16 Aug 2004 19:09:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GMv5Dc003081; Mon, 16 Aug 2004 15:57:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GMv5hn003080; Mon, 16 Aug 2004 15:57:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GMv4vi003060 for ; Mon, 16 Aug 2004 15:57:04 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 4D7AF7C22E; Tue, 17 Aug 2004 01:49:18 +0200 (CEST) Date: Tue, 17 Aug 2004 00:59:09 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= To: "Antone Roundy" Subject: Re: Shipping Atom products prematurely Cc: Atom-Syntax References: <25DEA200-EF9C-11D8-9AF1-003065EA6144@geckotribe.com> Message-ID: Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <25DEA200-EF9C-11D8-9AF1-003065EA6144@geckotribe.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 16 Aug 2004 09:51:33 -0600, Antone Roundy wrote: > I would think that we'd like to recommend not shipping Atom in > mass-market PUBLISHING tools till it's done, but off the top of my head, > I don't see any problem with shipping it in CONSUMING tools. +0.5. I can't see any major problems with allowing consumer tools to have flaky Atom support; it's almost always the producers that are the problem. Unless the producers generate Atom documents to fit buggy clients, that is. That could happen too. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Aug 16 21:58:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29726 for ; Mon, 16 Aug 2004 21:58:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H1kw1C015455; Mon, 16 Aug 2004 18:46:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7H1kwVt015454; Mon, 16 Aug 2004 18:46:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H1kvNP015442 for ; Mon, 16 Aug 2004 18:46:57 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7H1l0uo007589; Mon, 16 Aug 2004 21:47:01 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BNH94690 (AUTH bob@wyman.us); Mon, 16 Aug 2004 21:46:59 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Mark Nottingham'" , "'Atom WG'" Subject: RE: Shipping Atom products prematurely Date: Mon, 16 Aug 2004 21:49:15 -0400 Message-ID: <001501c483fc$6705ff20$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > I think the WG should proactively contact vendors of consumer > products and services and ask them to refrain from integrating > Atom support until it's done. I don't get it. Just a few months ago, the fact that LiveJournal, Blogger, and Typepad supported Atom 0.3 was proclaimed to be a wonderful thing. Now, some seem to be saying that it is bad if others do what was once considered good. How can this make sense? When you speak of "Atom" what is it that you are referring to? Is it the Atom 0.3 that people were once encouraged to support or is it the Atom format that is being defined in ID's today? I can understand if you say that people shouldn't ship support for Atom as defined in the IETF ID's, however, how can you object to people implementing what LiveJournal, Blogger, Typepad, and many others have implemented and been acclaimed for implementing? I realize that it will be messy getting people to move from Atom 0.3 to Atom 1.0. However, this is no more messy then getting them to move from any of the many flavors of RSS. bob wyman From owner-atom-syntax@mail.imc.org Mon Aug 16 23:28:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03794 for ; Mon, 16 Aug 2004 23:28:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H39a6L022211; Mon, 16 Aug 2004 20:09:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7H39aZi022210; Mon, 16 Aug 2004 20:09:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H39ZS1022204 for ; Mon, 16 Aug 2004 20:09:35 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id D035F727D; Mon, 16 Aug 2004 20:09:41 -0700 (PDT) In-Reply-To: <001501c483fc$6705ff20$6400a8c0@wyman.us> References: <001501c483fc$6705ff20$6400a8c0@wyman.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Shipping Atom products prematurely Date: Mon, 16 Aug 2004 20:09:41 -0700 To: X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 16, 2004, at 6:49 PM, Bob Wyman wrote: > I don't get it. Just a few months ago, the fact that > LiveJournal, Blogger, and Typepad supported Atom 0.3 was proclaimed to > be a wonderful thing. Now, some seem to be saying that it is bad if > others do what was once considered good. How can this make sense? Please re-read what I wrote. If people go out of their way to get an Atom client, or to consume an Atom feed, that's fine. It's not fine if products or services put Atom into the hands of people who aren't aware of what it or syndication is before we're done. LiveJournal, Blogger and Typepad were/are relatively small services that have a fairly technically savvy customer base, compared to the unwashed masses. Personally, I was somewhat uncomfortable with early adoption like this, but it was a limited deployment and didn't have too many bad effects. However, people are starting to talk about building Atom into operating systems, browsers, and other non-specialist software, and that will have a lot of effects that will be very difficult to manage. Note that there's a difference between announcing intended support for Atom -- which is wonderful -- and shipping products that depend on an unfinished spec. > When you speak of "Atom" what is it that you are referring to? > Is it the Atom 0.3 that people were once encouraged to support or is it > the Atom format that is being defined in ID's today? Both. > I realize that it will be messy getting people to move from Atom > 0.3 to Atom 1.0. However, this is no more messy then getting them to > move from any of the many flavors of RSS. We can and should do better than that. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 16 23:54:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04795 for ; Mon, 16 Aug 2004 23:54:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H3Or1x024049; Mon, 16 Aug 2004 20:24:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7H3OrUT024048; Mon, 16 Aug 2004 20:24:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H3OqRN024028 for ; Mon, 16 Aug 2004 20:24:52 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 17 Aug 2004 13:31:02 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 Aug 2004 13:24:24 +1000 Subject: Re: Shipping Atom products prematurely From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7H3OrRN024042 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 17/8/04 8:59 AM, "Asbjørn Ulsberg" wrote: >> I would think that we'd like to recommend not shipping Atom in >> mass-market PUBLISHING tools till it's done, but off the top of my head, >> I don't see any problem with shipping it in CONSUMING tools. > > +0.5. I can't see any major problems with allowing consumer tools to have > flaky Atom support; it's almost always the producers that are the problem. > Unless the producers generate Atom documents to fit buggy clients, that > is. That could happen too. There is a third category too -- mass-market publishing tools which are NOT SHIPPED, but are instead a centralised service. Like Blogger. They have complete control over their software, and can roll out an update which affects ALL their users at once. This is different as from a user-installed product for which there will always be old versions lingering around. I don't see any major problems with a centralised service rolling out more-stable-than-not versions of Atom. They shouldn't roll out do-not-deploy versions except as an undocumented *extra*, one which could disappear at any time. e. From owner-atom-syntax@mail.imc.org Tue Aug 17 00:02:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05382 for ; Tue, 17 Aug 2004 00:02:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H3dVBm025063; Mon, 16 Aug 2004 20:39:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7H3dV6R025062; Mon, 16 Aug 2004 20:39:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H3dUxk025056 for ; Mon, 16 Aug 2004 20:39:30 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 7986D727D; Mon, 16 Aug 2004 20:39:37 -0700 (PDT) In-Reply-To: <25DEA200-EF9C-11D8-9AF1-003065EA6144@geckotribe.com> References: <25DEA200-EF9C-11D8-9AF1-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0FEEB92D-EFFF-11D8-9BC6-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Shipping Atom products prematurely Date: Mon, 16 Aug 2004 20:39:37 -0700 To: Antone Roundy X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 16, 2004, at 8:51 AM, Antone Roundy wrote: > On Monday, August 16, 2004, at 09:22 AM, Mark Nottingham wrote: >> Ah; I misunderstood your question. My suggestion would be to not ship >> Atom in mass-market products until it's done (or at least close to >> being done). RSS is already out there. >> > I would think that we'd like to recommend not shipping Atom in > mass-market PUBLISHING tools till it's done, but off the top of my > head, I don't see any problem with shipping it in CONSUMING tools. Am > I missing something? Vendor A ships 10 million units of their software that includes support for reading Atom feeds. Now, every time we suggest that something change in the spec, we run up against the "but it's already on 10 million desktops" argument. This is especially worrisome, considering that we haven't yet made versioning and extensibility bulletproof. I don't want this to be a huge issue; however, the expectations need to be managed. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 17 00:08:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05587 for ; Tue, 17 Aug 2004 00:08:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7H3qVHW026120; Mon, 16 Aug 2004 20:52:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7H3qVJG026119; Mon, 16 Aug 2004 20:52:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7H3qVSW026101 for ; Mon, 16 Aug 2004 20:52:31 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040817035233.88518.qmail@web41207.mail.yahoo.com> Received: from [64.136.27.225] by web41207.mail.yahoo.com via HTTP; Mon, 16 Aug 2004 20:52:33 PDT Date: Mon, 16 Aug 2004 20:52:33 -0700 (PDT) From: Dare Obasanjo Subject: Re: Shipping Atom products prematurely To: Mark Nottingham , bob@wyman.us Cc: "'Atom WG'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Mark Nottingham wrote: > > On Aug 16, 2004, at 6:49 PM, Bob Wyman wrote: > > I don't get it. Just a few months ago, the fact > that > > LiveJournal, Blogger, and Typepad supported Atom > 0.3 was proclaimed to > > be a wonderful thing. Now, some seem to be saying > that it is bad if > > others do what was once considered good. How can > this make sense? I dislike generic statements like these. Whoever said it was great that Google was adopting the Atom 0.3 syndication format it wasn't me. For all I know, the same people who said it was great then still think it is now. I thought it was a bad idea then and I still think it was a dumb thing to do now. > LiveJournal, Blogger and Typepad were/are relatively > small services > that have a fairly technically savvy customer base, > compared to the > unwashed masses. Personally, I was somewhat > uncomfortable with early > adoption like this, but it was a limited deployment > and didn't have too > many bad effects. I wouldn't call services that have over a million active users (Blogger and LiveJournal) as small services nor would I claim that they have a fairly technically savvy audience. I suspect you are confusing the multitude of MovableType users who are Perl savvy and pipe up in RSS discussions with the average teenage girl or college freshman who's publishing their diary on Blogger. > However, people are starting to talk about building > Atom into operating > systems, browsers, and other non-specialist > software, and that will > have a lot of effects that will be very difficult to > manage. Interesting. Which operating systems and browsers have announced Atom support? > Note that there's a difference between announcing > intended support for > Atom -- which is wonderful -- and shipping products > that depend on an > unfinished spec. Agreed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 17 06:37:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06148 for ; Tue, 17 Aug 2004 06:37:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HAAXdk099459; Tue, 17 Aug 2004 03:10:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HAAXeW099458; Tue, 17 Aug 2004 03:10:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HAAW90099452 for ; Tue, 17 Aug 2004 03:10:33 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id A8B844F0B2; Tue, 17 Aug 2004 06:10:33 -0400 (EDT) Date: Tue, 17 Aug 2004 06:10:33 -0400 From: Dan Brickley To: Mark Nottingham Cc: Antone Roundy , atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely Message-ID: <20040817101033.GC12124@homer.w3.org> References: <25DEA200-EF9C-11D8-9AF1-003065EA6144@geckotribe.com> <0FEEB92D-EFFF-11D8-9BC6-000A95BD86C0@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0FEEB92D-EFFF-11D8-9BC6-000A95BD86C0@mnot.net> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Mark Nottingham [2004-08-16 20:39-0700] > > > On Aug 16, 2004, at 8:51 AM, Antone Roundy wrote: > > >On Monday, August 16, 2004, at 09:22 AM, Mark Nottingham wrote: > >>Ah; I misunderstood your question. My suggestion would be to not ship > >>Atom in mass-market products until it's done (or at least close to > >>being done). RSS is already out there. > >> > >I would think that we'd like to recommend not shipping Atom in > >mass-market PUBLISHING tools till it's done, but off the top of my > >head, I don't see any problem with shipping it in CONSUMING tools. Am > >I missing something? > > Vendor A ships 10 million units of their software that includes support > for reading Atom feeds. Now, every time we suggest that something > change in the spec, we run up against the "but it's already on 10 > million desktops" argument. > > This is especially worrisome, considering that we haven't yet made > versioning and extensibility bulletproof. +1, please let's not have to leave extensibility and versioning for v2.0 because of this. > I don't want this to be a huge issue; however, the expectations need to > be managed. Yup. For sites *producing* Atom feeds, perhaps encourage a bit of boilerplate at the top of the file in XML comments, perhaps something like: ...or words along those lines? Less wordy might be wise, for big sites with lots of feeds... (eg. a pointer to text elsewhere perhaps) cheers, Dan From owner-atom-syntax@mail.imc.org Tue Aug 17 10:53:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20916 for ; Tue, 17 Aug 2004 10:53:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HEceN6050629; Tue, 17 Aug 2004 07:38:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HEce7V050628; Tue, 17 Aug 2004 07:38:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HEccMr050601 for ; Tue, 17 Aug 2004 07:38:40 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1Bx56g-0005zG-Rd for atom-syntax@imc.org; Tue, 17 Aug 2004 14:38:37 +0000 Message-ID: <41221867.90002@franklinmint.fm> Date: Tue, 17 Aug 2004 10:38:31 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PacePostLocationMust Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > PacePostLocationMust seems to be a small clarification, unlikely to be > very controversial. +1 on PacePostLocationMust. Any objections? Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 17 11:22:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22827 for ; Tue, 17 Aug 2004 11:22:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HEuU88054307; Tue, 17 Aug 2004 07:56:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HEuUZO054306; Tue, 17 Aug 2004 07:56:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HEuT7C054281 for ; Tue, 17 Aug 2004 07:56:29 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040817145622.84732.qmail@web41213.mail.yahoo.com> Received: from [64.136.27.225] by web41213.mail.yahoo.com via HTTP; Tue, 17 Aug 2004 07:56:22 PDT Date: Tue, 17 Aug 2004 07:56:22 -0700 (PDT) From: Dare Obasanjo Subject: Re: Shipping Atom products prematurely To: Dan Brickley , Mark Nottingham Cc: Antone Roundy , atom-syntax@imc.org In-Reply-To: <20040817101033.GC12124@homer.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Dan Brickley wrote: > > Yup. For sites *producing* Atom feeds, perhaps > encourage a bit of > boilerplate at the top of the file in XML comments, > perhaps something > like: > > This boiler plate is meaningless. Why would a regular aggregator user see it or even care? Once Google made Atom 0.3 the only format supported by certain Blogger sites aggregator authors were pressured to implement a interim version of the draft spec. There are now literally thousands of desktop aggregators that support Atom 0.3 on users desktops. I've counted aboyut 50,000 downloads of RSS Bandit versions wioth Atom 0.3 support. Both FeedDemon and SharpReader are more popular so it isn't inconceivable for there to be 100,000 - 200,000 users out there who are dependent on major sityes providing Atom 0.3 feeds. This number is growing by tens of thousands of users a month. What the heck is going to happen once Atom 1.0 comes out. Will all these users be out of luck or will Google/Blogger continue supporting Atom 0.3 indefinitely? What happens when even more sites follow Google's lead? Finally, how the does putting some comments in an XML file actually help this problem? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 17 11:41:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24134 for ; Tue, 17 Aug 2004 11:41:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFRbBs059710; Tue, 17 Aug 2004 08:27:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HFRbeM059709; Tue, 17 Aug 2004 08:27:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFRbIc059701 for ; Tue, 17 Aug 2004 08:27:37 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1Bx5s6-0005Dh-HG; Tue, 17 Aug 2004 15:27:34 +0000 Message-ID: <412223E2.1010403@franklinmint.fm> Date: Tue, 17 Aug 2004 11:27:30 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Dan Brickley , Mark Nottingham , Antone Roundy , atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> In-Reply-To: <20040817145622.84732.qmail@web41213.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > What the heck is going to happen once Atom 1.0 comes > out. Will all these users be out of luck or will > Google/Blogger continue supporting Atom 0.3 > indefinitely? What happens when even more sites follow > Google's lead? > How about they deploy the Atom 1.0 feeds at new URIs, and permanently redirect the Atom 0.3 feeds after a reasonable period of time. I got sick of maintaining RSS feeds on my own site, so I stuck permanent redirects from the old RSS URIs to the Atom feed. Seemed to work just fine. After a month or so, I rarely got requests for the RSS files. Mark Nottingham wrote: > > Remember that the deployment footprint of Atom is still relatively > small, especially on the consumer side; if we don't check this, it will > be very large, and people will start arguing "we can't change feature X > in the draft because vendor Y has already shipped n million units that > depend upon it." While I share your concern, I think it's too late. The best-of-breed clients already support Atom 0.3. I think Radio is the only major client that doesn't. It's a capability that consumers expect, and competitors will point out "lack of Atom support" if an aggregator doesn't support 0.3. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 17 11:56:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24859 for ; Tue, 17 Aug 2004 11:56:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFevAk062103; Tue, 17 Aug 2004 08:40:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HFeve5062102; Tue, 17 Aug 2004 08:40:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFeudT062084 for ; Tue, 17 Aug 2004 08:40:57 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc12) with SMTP id <2004081715405401200d51g5e>; Tue, 17 Aug 2004 15:40:54 +0000 Date: Tue, 17 Aug 2004 09:40:52 -0600 Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <20040817145622.84732.qmail@web41213.mail.yahoo.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday, August 17, 2004, at 08:56 AM, Dare Obasanjo wrote: > Once Google made Atom 0.3 the only format supported by > certain Blogger sites aggregator authors were > pressured to implement a interim version of the draft > spec. There are now literally thousands of desktop > aggregators that support Atom 0.3 on users desktops. > I've counted aboyut 50,000 downloads of RSS Bandit > versions wioth Atom 0.3 support. Both FeedDemon and > SharpReader are more popular so it isn't inconceivable > for there to be 100,000 - 200,000 users out there who > are dependent on major sityes providing Atom 0.3 > feeds. This number is growing by tens of thousands of > users a month. > > What the heck is going to happen once Atom 1.0 comes > out. Will all these users be out of luck or will > Google/Blogger continue supporting Atom 0.3 > indefinitely? What happens when even more sites follow > Google's lead? > If "Google [makes] Atom [1.0] the only format supported by certain Blogger sites aggregator authors [will be] pressured to implement ... version [1.0] of the ... spec." Those users won't be any more out of luck than they were when Google moved from RSS to Atom 0.3. They'll have to wait however long it takes till aggregator authors implement Atom 1.0 support, and then upgrade their aggregator. Google could, of course, continue to support 0.3 for a while, perhaps enabling each blog to have 2 versions of the feed. After a few months, or however long seems appropriate, they could drop 0.3 support. Anybody who hadn't bothered setting up a 1.0 feed but did have an 0.3 feed could suddenly find it changed to 1.0. Anybody who had both would end up with just the one. Antone P.S. No need to CC me on messages on this thread...or any other thread for that matter. From owner-atom-syntax@mail.imc.org Tue Aug 17 12:00:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25102 for ; Tue, 17 Aug 2004 12:00:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFkIua063120; Tue, 17 Aug 2004 08:46:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HFkIOG063119; Tue, 17 Aug 2004 08:46:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFkHOp063110 for ; Tue, 17 Aug 2004 08:46:17 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 802BD727D; Tue, 17 Aug 2004 08:46:20 -0700 (PDT) In-Reply-To: <20040817145622.84732.qmail@web41213.mail.yahoo.com> References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <940D2EBA-F064-11D8-9BC6-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Shipping Atom products prematurely Date: Tue, 17 Aug 2004 08:46:17 -0700 To: Dare Obasanjo X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 17, 2004, at 7:56 AM, Dare Obasanjo wrote: > This boiler plate is meaningless. Why would a regular > aggregator user see it or even care? I tend to agree. I was hoping that this group could come to an easy consensus about this (after all, it's pretty clear in the I-Ds), work with the vendors present to make sure that any products or services are appropriate, and reach out to vendors who aren't participating in this group to do the same. The high points, in my mind, would be: - do not ship Atom support in "final" products; use clearly marked vehicles like "alpha" "beta" or "experimental." - likewise, clearly mark use of "Atom" in links, marketing and other documentation as "experimental" - support mature alternatives (e.g., RSS) at least until Atom is final - have an acceptable transition plan that forces upgrade (e.g., time-expired betas, removing old feeds) The last one is especially important, because many larger, mass-market products and services will be reluctant to "break" people who are depending on the previous behaviour. If they're not willing to do that, they shouldn't be using Atom right now. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 17 12:15:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25889 for ; Tue, 17 Aug 2004 12:15:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFsUQQ064501; Tue, 17 Aug 2004 08:54:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HFsUba064500; Tue, 17 Aug 2004 08:54:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HFsTV3064454 for ; Tue, 17 Aug 2004 08:54:29 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id IAA06277 for ; Tue, 17 Aug 2004 08:54:27 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id IAA17923 for ; Tue, 17 Aug 2004 08:54:26 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Tue, 17 Aug 2004 08:54:26 -0700 Received: from adsl-64-166-133-244.dsl.snfc21.pacbell.net (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2L006MJLINDF@shazam.verity.com> for atom-syntax@imc.org; Tue, 17 Aug 2004 08:54:25 -0700 (PDT) Date: Tue, 17 Aug 2004 08:54:22 -0700 From: Walter Underwood X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy Subject: Re: Shipping Atom products prematurely In-reply-to: <20040817101033.GC12124@homer.w3.org> To: atom-syntax@imc.org Message-id: <3C54662F0957D4A3FD9E0CBC@adsl-64-166-133-244.dsl.snfc21.pacbell.net> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <25DEA200-EF9C-11D8-9AF1-003065EA6144@geckotribe.com> <0FEEB92D-EFFF-11D8-9BC6-000A95BD86C0@mnot.net> <20040817101033.GC12124@homer.w3.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT --On Tuesday, August 17, 2004 6:10 AM -0400 Dan Brickley wrote: >> >> This is especially worrisome, considering that we haven't yet made >> versioning and extensibility bulletproof. > > +1, please let's not have to leave extensibility and versioning for v2.0 > because of this. This can be handled by something much simpler than protocol versioning. For example, the protocol drafts can specify the root element as , then change it when published. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 17 13:02:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29627 for ; Tue, 17 Aug 2004 13:02:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HGjgxa074053; Tue, 17 Aug 2004 09:45:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HGjg9a074052; Tue, 17 Aug 2004 09:45:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HGjdvk074029 for ; Tue, 17 Aug 2004 09:45:42 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 59055 messnum 4164780 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 17 Aug 2004 16:45:37 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail00.svc.cra.dublin.eircom.net (qp 59055) with SMTP; 17 Aug 2004 16:45:37 -0000 Message-ID: <4122362F.1070006@dehora.net> Date: Tue, 17 Aug 2004 17:45:35 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> In-Reply-To: <20040817145622.84732.qmail@web41213.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > This boiler plate is meaningless. Why would a regular > aggregator user see it or even care? > Once Google made Atom 0.3 the only format supported by > certain Blogger > > [...] > > What the heck is going to happen once Atom 1.0 comes > out. Will all these users be out of luck or will > Google/Blogger continue supporting Atom 0.3 > indefinitely? What happens when even more sites follow > Google's lead? So many questions. What do you suggest should be done, if anything? cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 17 13:15:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00599 for ; Tue, 17 Aug 2004 13:15:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HH6Pnd078072; Tue, 17 Aug 2004 10:06:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HH6PGI078071; Tue, 17 Aug 2004 10:06:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pulse.betaversion.org ([62.140.213.123]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HH6Oo9078057 for ; Tue, 17 Aug 2004 10:06:24 -0700 (PDT) (envelope-from pier@betaversion.org) Received: (qmail 13404 invoked from network); 17 Aug 2004 17:06:24 -0000 Received: from unknown (HELO ?10.11.155.45?) (pier@62.140.213.2) by pulse.betaversion.org with SMTP; 17 Aug 2004 17:06:24 -0000 Mime-Version: 1.0 (Apple Message framework v619) To: atom-syntax@imc.org Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-638551194; protocol="application/pkcs7-signature" From: Pier Fumagalli Subject: Syndication of updates and deletions of content Date: Tue, 17 Aug 2004 18:06:24 +0100 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3-638551194 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi all, A very short introduction of myself: my name is Pier and I've been somehow involved with Apache for the past 7 years... I currently work for VNU Business Publications in London, and being in the publishing market, we're starting to look at different ways to use syndication protocols throughout our systems. I'd like to start by saying that (for the moment) I am not talking about Atom's Publishing Protocol, but rather of the Syndication format, which (for us) is at the moment more pressing. The one thing I find difficult when reading throughout the Syndication Format specification is whether it allows the syndication of "deleted" resources. Let's start with a very very very simple example: I have an article about Windows XP SP2, and what can happen on this resource is that it can either be published or deleted. Published is easy, yesterday there was no resource, today we have one. In Atom, I would syndicate this as: VNUNET.COM Feed 2004-08-17T16:23.52Z VNU Business Publications Limited Microsoft lists apps affected by XP SP2 http://www.vnunet.com/news/1157398 Iain Thomson 2004-08-17T08:29:29Z 2004-08-17T08:29:29Z .... This means that a resource has been published. In this format I can also specify that a resource was modified, if (for example) the modified date specified in the new feed is different from the original feed in which it first appeared. I cover, basically, insertions and modifications of resources with no problems. Now, how would I syndicate the fact that a resource is gone away? Of course I won't include in the syndication feed all of our content (more than 100k articles), but only what happened in the (let's say) past 24 hours. But how can a subscriber to my Atom feed know whether a resource is simply not included, or it was actually removed? I thought about having an "entry" structured in this way: Microsoft lists apps affected by XP SP2 http://www.vnunet.com/news/1157398 2004-08-17T08:29:29Z but I'm not sure whether this makes sense... Probably it might be better not to include the tag, as it wouldn't make sense anymore (what's the title of a non-existant resource), but I'm just shooting out ideas. What do you guys think? Is there already a way to do this? Thanks to you all... Pier --Apple-Mail-3-638551194 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwttIjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTA3MDE0MjIwWhcNMDUwMTA2MDE0MjIwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRwaWVyQGJldGF2ZXJzaW9u Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMC/E+M4UqeEBnSTj0AIMX9oMWSo 9Te7VUPPvINPSKKLEElGaottQeJaYRSlfGIjUyXkzTlbw0MFAPaqfU97t+5xeNkighKu7ZcVIPfz AARv5+wp+gON5uSNV2GzP0rPwAbUDIG2zaSonJlN7whVG5fO9G1u0oYaWolpgKUAc3T5P5Gv737L G1iSxrnl9DQlVDIuZWrcgWYX/MFFlf7prXXm6lS08lYhGi0NrIf5SploZzMG+uHHzVDgV8WCTQr1 hXB825VLhnWw4GPFx5qLVgElctVz88S/+t8O/+1kRf3ky8SsewfyCTuDAk4XHzfb7M5bECiZ1yni dhW+sD1y/TsCAwEAAaMxMC8wHwYDVR0RBBgwFoEUcGllckBiZXRhdmVyc2lvbi5vcmcwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAjeSEnk3U1P46rHiBGJP7StkQg/DVkw4ModEYCEwxm 8QYxQPGMciXn2goZ5ahK6Uu8Rfa+ZPSxV96VFsOlc3oFF02VYsrRy+xJukuSMY0z/0UvHnTZmVfm CJpxMoVMYQO3fC2XdmCNASu8FbvOgaS71fQf3b0wgebLeLROR7u5XjCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC20iMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxNzE3MDYyNFowIwYJKoZIhvcNAQkEMRYEFGsR QXaxxnQS2NPE8DvsiR8ug+Q2MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLbSIwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC20iMA0GCSqGSIb3DQEBAQUABIIBAGDC SJTcXbtDKgh4WPbq4s7ZT7I6TY+o/wKygmgy54FTtHWPPKuStvPxwAOWZs/4Vo6zFCbwMsefAxOO jfsgCpdf8jtAIlYuFoAYx7lRB6sa/Ag2yDSSb55Jm3fovR8vyojV3loi7DwV3RDi3mqAb/wtrHwh 3rcBhPVg/nKEXiZOTf+h/ohjB15VuVyEsGGzmMmEWqvZEl/aoijNHkQy4lC5wKicFSGSpKUZsuWJ NOXrCKkwszWQWfC8vB9kP6lEhQJW8+i/jUsjQdhPxBmJ12C5iYlKM39f1KddfGnxymrG+L6+R8EO r4ZS63lYB7R/5hDg3MCn3N8vwzkxTYkShicAAAAAAAA= --Apple-Mail-3-638551194-- From owner-atom-syntax@mail.imc.org Tue Aug 17 13:32:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01935 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 13:32:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HHFSJU080422; Tue, 17 Aug 2004 10:15:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HHFSA1080417; Tue, 17 Aug 2004 10:15:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hydra.nt-dns.com (black.mydnspages.com [216.180.241.138] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HHFRv0080357 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 10:15:27 -0700 (PDT) (envelope-from luke@hutteman.com) Received: from cpanel by hydra.nt-dns.com with local (Exim 4.34) id 1Bx7YV-00039c-MP; Tue, 17 Aug 2004 13:15:27 -0400 Received: from 162.111.235.34 ([162.111.235.34]) by www.hutteman.com (IMP) with HTTP for <luke@hutteman.com@localhost>; Tue, 17 Aug 2004 13:15:27 -0400 Message-ID: <1092762927.41223d2fa1233@www.hutteman.com> Date: Tue, 17 Aug 2004 13:15:27 -0400 From: luke@hutteman.com To: atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> In-Reply-To: <20040817145622.84732.qmail@web41213.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 162.111.235.34 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hydra.nt-dns.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [32001 32001] / [47 12] X-AntiAbuse: Sender Address Domain - hutteman.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Quoting Dare Obasanjo <kpako@yahoo.com>: > This boiler plate is meaningless. Why would a regular > aggregator user see it or even care? Agreed. > Once Google made Atom 0.3 the only format supported by > certain Blogger sites aggregator authors were > pressured to implement a interim version of the draft > spec. There are now literally thousands of desktop > aggregators that support Atom 0.3 on users desktops. I wasn't a big fan of Google's decision either, as like you said, it essentially forced aggregator authors to implement a spec that was not yet finalized. And once more aggregators started supporting it, more sites in turn have started publishing Atom 0.3 feeds. This has gotten us to a point where when a new version of Atom is published, there will still remain many published feeds out there that still use the old (incompatible) spec., meaning aggregators will need to continue to support these out-of-date Atom specs. There is a certain individual who shall remain nameless who loves to blog about the many incompatibilities between RSS versions. The widespread current adoption of Atom 0.3 pretty much guarantees it will end up the same way. It may even be worse because while new versions of RSS have given SOME thought to backward compatibility (even if that compatibility wasn't perfect), Atom won't as the previous spec was not final anyway. > I've counted aboyut 50,000 downloads of RSS Bandit > versions wioth Atom 0.3 support. Both FeedDemon and > SharpReader are more popular so it isn't inconceivable > for there to be 100,000 - 200,000 users out there who > are dependent on major sityes providing Atom 0.3 > feeds. This number is growing by tens of thousands of > users a month. > > What the heck is going to happen once Atom 1.0 comes > out. Will all these users be out of luck or will > Google/Blogger continue supporting Atom 0.3 > indefinitely? What happens when even more sites follow > Google's lead? The users will be fine. Aggregator authors will just be forced to implement Atom 1.0. Unfortunately, as stated above, Atom 0.3 (and 0.4, 0.5 or any other intermediate versions there may be) will still need to be supported as well. > Finally, how the does putting some comments in an XML > file actually help this problem? It won't. Aggregator authors should already be well aware of this stuff. It's feed publishers that should be reminded somehow to upgrade to the latest Atom spec when this is released. While this issue could theoretically be forced if all aggregator authors were to agree to stop supporting Atom 0.3, I seriously doubt this will happen. It's a prisoner's dilemma - if we all agree to do it, we'd all be better off eventually. If a few continue to support 0.3 though, they'd have an edge which would allow them more users at the expense of the conforming aggregators, which would force those to reactivate 0.3 support. This in turn means there will be little incentive for anyone to upgrade their then outdated 0.3 feed to the latest release. I'd welcome any suggestions on how to solve this problem - quite frankly, I'm not sure there is a solution though... unless there's some legal mumbo jumbo that could be put in the final spec that required any product that uses the Atom 1.0 spec stop supporting any previous versions (beyond that which come automatically due to backwards compatibility of course) after a certain date. I'm no lawyer so I have no idea if this would be possible, but even if it is, the open nature of Atom doesn't seem to mix too well with these kinds of restrictions... From owner-atom-syntax@mail.imc.org Tue Aug 17 14:27:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05143 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 14:27:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIIDCu086316; Tue, 17 Aug 2004 11:18:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HIIDIJ086315; Tue, 17 Aug 2004 11:18:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIIA1u086307 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 11:18:10 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p06110446bd47f9e2a532@[10.20.30.249]> In-Reply-To: <1092762927.41223d2fa1233@www.hutteman.com> References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> <1092762927.41223d2fa1233@www.hutteman.com> Date: Tue, 17 Aug 2004 11:17:53 -0700 To: atom-syntax@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 1:15 PM -0400 8/17/04, luke@hutteman.com wrote: >Aggregator authors will just be forced to implement >Atom 1.0. Unfortunately, as stated above, Atom 0.3 (and 0.4, 0.5 or any other >intermediate versions there may be) will still need to be supported as well. That's not at all clear. So far, we have only seen the pre-IETF version 0.3 in the wild. I have heard of zero reports of implementations of the -00 or -01 drafts that have been seen in feeds. This is a Very Good Thing. FWIW, the 0.3 version doesn't even exist as an IETF Internet Draft. Any vendor who implements from anything other than the final IETF standard will have a host of problems interoperating in the future. IETF documents expire after six months, and are usually unavailable within nine months. So, if someone releases code based on draft-ietf-atompub-format-07.txt, that document will soon become unavailable, meaning that someone else cannot determine how to interop with it in the future. Of course, the RFCs we produce will live forever. You can still find RFC 1 on IMP software at <ftp://ftp.rfc-editor.org/in-notes/rfc1.txt> 35 years later. The Atompub WG *will* have proper and understandable versioning in both the format and protocol before we are finished. Until the final, standardized version, the documents will make it clear that implementers should only implement for internal use. If we find some implementers creating feeds from pre-standards IETF drafts, a bit of quick public education can probably fix the problem. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 17 14:37:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06021 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 14:37:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIPYMe086721; Tue, 17 Aug 2004 11:25:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HIPY40086720; Tue, 17 Aug 2004 11:25:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HIPXoE086709 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 11:25:33 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040817182527.77434.qmail@web41209.mail.yahoo.com> Received: from [207.46.238.137] by web41209.mail.yahoo.com via HTTP; Tue, 17 Aug 2004 11:25:27 PDT Date: Tue, 17 Aug 2004 11:25:27 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Shipping Atom products prematurely To: luke@hutteman.com, atom-syntax@imc.org In-Reply-To: <1092762927.41223d2fa1233@www.hutteman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- luke@hutteman.com wrote: > > > > What the heck is going to happen once Atom 1.0 > comes > > out. Will all these users be out of luck or will > > Google/Blogger continue supporting Atom 0.3 > > indefinitely? What happens when even more sites > follow > > Google's lead? > > The users will be fine. Aggregator authors will just > be forced to implement > Atom 1.0. Unfortunately, as stated above, Atom 0.3 > (and 0.4, 0.5 or any other > intermediate versions there may be) will still need > to be supported as well. The implicit assumption is that tens of thousands to hundreds of thousands of users will be forced to upgrade. This doesn't seem like a good option to me since it leads to a negative user experience but it doesn't seem like we have any choice. I still remember all the negative feedback when Mark Pilgrim switched his blog to providing Atom-only feeds. :( ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 17 14:46:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06779 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 14:46:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIc9oU087564; Tue, 17 Aug 2004 11:38:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HIc92b087563; Tue, 17 Aug 2004 11:38:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIc94k087554 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 11:38:09 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so180961rnl for <atom-syntax@imc.org>; Tue, 17 Aug 2004 11:38:12 -0700 (PDT) Received: by 10.38.13.31 with SMTP id 31mr207476rnm; Tue, 17 Aug 2004 11:38:12 -0700 (PDT) Message-ID: <14be96d304081711382d3d1ab8@mail.gmail.com> Date: Tue, 17 Aug 2004 14:38:12 -0400 From: Mark Pilgrim <pilgrim@gmail.com> Reply-To: Mark Pilgrim <pilgrim@gmail.com> To: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Shipping Atom products prematurely Cc: atom-syntax@imc.org In-Reply-To: <20040817182527.77434.qmail@web41209.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040817182527.77434.qmail@web41209.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Tue, 17 Aug 2004 11:25:27 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> wrote: > The implicit assumption is that tens of thousands to > hundreds of thousands of users will be forced to > upgrade. This doesn't seem like a good option to me > since it leads to a negative user experience but it > doesn't seem like we have any choice. I still remember > all the negative feedback when Mark Pilgrim switched > his blog to providing Atom-only feeds. :( I must have missed the part where I was put under any obligation towards you whatsoever. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 17 14:50:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06943 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 14:50:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIgabH087801; Tue, 17 Aug 2004 11:42:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HIgaKm087800; Tue, 17 Aug 2004 11:42:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HIga8S087790 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 11:42:36 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040817184234.74995.qmail@web41212.mail.yahoo.com> Received: from [131.107.76.143] by web41212.mail.yahoo.com via HTTP; Tue, 17 Aug 2004 11:42:34 PDT Date: Tue, 17 Aug 2004 11:42:34 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Shipping Atom products prematurely To: Mark Pilgrim <pilgrim@gmail.com> Cc: atom-syntax@imc.org In-Reply-To: <14be96d304081711382d3d1ab8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Mark Pilgrim <pilgrim@gmail.com> wrote: > > > The implicit assumption is that tens of thousands > to > > hundreds of thousands of users will be forced to > > upgrade. This doesn't seem like a good option to > me > > since it leads to a negative user experience but > it > > doesn't seem like we have any choice. I still > remember > > all the negative feedback when Mark Pilgrim > switched > > his blog to providing Atom-only feeds. :( > > I must have missed the part where I was put under > any obligation > towards you whatsoever. The point is that forcing users to upgrade their aggregator to read a feed they could read just fine a day before results in pissed off users and I provided a real-world example. I'm not sure where a claim that Mark Pilgrim is obligated to Dare Obasanjo arises from the above statement. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 17 15:00:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07470 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:00:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIkRfk088039; Tue, 17 Aug 2004 11:46:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HIkRDB088038; Tue, 17 Aug 2004 11:46:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hydra.nt-dns.com (black.mydnspages.com [216.180.241.138] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIkRXn088031 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 11:46:27 -0700 (PDT) (envelope-from luke@hutteman.com) Received: from cpanel by hydra.nt-dns.com with local (Exim 4.34) id 1Bx8yZ-0000v2-Fd for atom-syntax@imc.org; Tue, 17 Aug 2004 14:46:27 -0400 Received: from 162.111.235.34 ([162.111.235.34]) by www.hutteman.com (IMP) with HTTP for <luke@hutteman.com@localhost>; Tue, 17 Aug 2004 14:46:27 -0400 Message-ID: <1092768387.4122528370504@www.hutteman.com> Date: Tue, 17 Aug 2004 14:46:27 -0400 From: luke@hutteman.com To: atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> <1092762927.41223d2fa1233@www.hutteman.com> <p06110446bd47f9e2a532@[10.20.30.249]> In-Reply-To: <p06110446bd47f9e2a532@[10.20.30.249]> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 162.111.235.34 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hydra.nt-dns.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [32001 32001] / [47 12] X-AntiAbuse: Sender Address Domain - hutteman.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Quoting Paul Hoffman / IMC <phoffman@imc.org>: > So far, we have only seen the pre-IETF version 0.3 in the wild. I > have heard of zero reports of implementations of the -00 or -01 > drafts that have been seen in feeds. This is a Very Good Thing. FWIW, > the 0.3 version doesn't even exist as an IETF Internet Draft. I've seen a few Atom 0.2 feeds in the wild, but agree that these are very sparse and therefore not much of a problem. Atom started getting much more popular with 0.3 though, so I expect this to become a bigger problem when the next version is published. > Until the final, standardized version, the documents will make it > clear that implementers should only implement for internal use. If we > find some implementers creating feeds from pre-standards IETF drafts, > a bit of quick public education can probably fix the problem. hmm... seems to me that "a bit of quick public education" might be overdue here... quite a few Atom 0.3 implementations out there that aren't internal... From owner-atom-syntax@mail.imc.org Tue Aug 17 15:09:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08635 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:09:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIvZJH088656; Tue, 17 Aug 2004 11:57:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HIvZec088655; Tue, 17 Aug 2004 11:57:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hydra.nt-dns.com (black.mydnspages.com [216.180.241.138] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HIvYxR088648 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 11:57:34 -0700 (PDT) (envelope-from luke@hutteman.com) Received: from cpanel by hydra.nt-dns.com with local (Exim 4.34) id 1Bx99N-0001db-6D; Tue, 17 Aug 2004 14:57:37 -0400 Received: from 162.111.235.34 ([162.111.235.34]) by www.hutteman.com (IMP) with HTTP for <luke@hutteman.com@localhost>; Tue, 17 Aug 2004 14:57:37 -0400 Message-ID: <1092769057.4122552127119@www.hutteman.com> Date: Tue, 17 Aug 2004 14:57:37 -0400 From: luke@hutteman.com To: Dare Obasanjo <kpako@yahoo.com> Cc: atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817182527.77434.qmail@web41209.mail.yahoo.com> In-Reply-To: <20040817182527.77434.qmail@web41209.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 162.111.235.34 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hydra.nt-dns.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [32001 32001] / [47 12] X-AntiAbuse: Sender Address Domain - hutteman.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Quoting Dare Obasanjo <kpako@yahoo.com>: > The implicit assumption is that tens of thousands to > hundreds of thousands of users will be forced to > upgrade. This doesn't seem like a good option to me > since it leads to a negative user experience but it > doesn't seem like we have any choice. I still remember > all the negative feedback when Mark Pilgrim switched > his blog to providing Atom-only feeds. :( I can see only two alternatives to this: 1) make all subsequent versions of Atom backwards compatible with Atom 0.3 (I think most here would agree this would be a bad idea) 2) put a recommendation in any pre-1.0 atom spec stating that, while experimenting is allowed (or even encouraged), authors should also publish a feed using a more mature and stable format (i.e. one of the RSS dialects) for use by aggregators that do no support this particular pre-1.0 Atom version yet (or not anymore, once a new version is published). From owner-atom-syntax@mail.imc.org Tue Aug 17 15:24:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10154 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:24:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJCuPY091416; Tue, 17 Aug 2004 12:12:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HJCuEP091415; Tue, 17 Aug 2004 12:12:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJCu11091409 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 12:12:56 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7HJD0Oo020140; Tue, 17 Aug 2004 12:13:00 -0700 (PDT) Received: from [10.232.7.124] ([17.255.240.30]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i7HJCwBA006013; Tue, 17 Aug 2004 12:12:59 -0700 (PDT) In-Reply-To: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-646144155; protocol="application/pkcs7-signature" Message-Id: <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> Cc: Atom WG <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: Shipping Atom products prematurely Date: Tue, 17 Aug 2004 14:12:56 -0500 To: Mark Nottingham <mnot@mnot.net> X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --Apple-Mail-1-646144155 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 15 Aug 2004, at 5:21 pm, Mark Nottingham wrote: > As such, I think the WG should proactively contact vendors of consumer > products and services and ask them to refrain from integrating Atom > support until it's done. They have the best of intentions by > supporting Atom, but may do more harm than good by accelerating the > adoption of it prematurely. Isn't the first step getting atomenabled.org taken off air? Graham --Apple-Mail-1-646144155 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODE3MTkxMjU3WjAjBgkqhkiG9w0BCQQxFgQUsRFr5CNpfId0yrk4MWwYAzcy 7XsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAhMGV0EwhPaZ2ng7ZgEnKwtox IuZxr37hHi9NmDY5UkbfUalV9DZHzHohvSy28cflOSalT824cufB+GnmZgGV6uM5/3/PsGm/nQfz PLNF+SEtKLThyz/UKpksoEGy9CCJvMMWEPzJZ0jx6Mbaojq5sDhCS2vvphedw4VAXOzEKsz266CD ppO1O5wNte337/Yscu8dfO8aLt1LEXyJfs8sknH20HRaT+Z/qwmDawy6zcctrDp8MFETdXw7TjcZ BN7lJHJpXz5pTbhXDyon5QT+e1LuZqkWACOcGtjuGyaos/r7eNYyBpaF7iJqXfE4iZJOXFPfQdPU Im/PkvlSvX62TwAAAAAAAA== --Apple-Mail-1-646144155-- From owner-atom-syntax@mail.imc.org Tue Aug 17 15:24:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10194 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:24:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJHEaY091735; Tue, 17 Aug 2004 12:17:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HJHE4E091734; Tue, 17 Aug 2004 12:17:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJHE6e091722 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 12:17:14 -0700 (PDT) (envelope-from jarober@gosmalltalk.com) Received: from victoria (pcp01741172pcs.howard01.md.comcast.net[68.54.83.139]) by comcast.net (rwcrmhc12) with ESMTP id <2004081719170701400l6osae>; Tue, 17 Aug 2004 19:17:13 +0000 Received: from james2.gosmalltalk.com (james [10.55.1.103]) by victoria (8.11.0/8.11.0) with ESMTP id i7HJH6R18758 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 15:17:06 -0400 Message-Id: <6.1.2.0.2.20040817151544.02eb37b0@www.gosmalltalk.com> X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 17 Aug 2004 15:16:46 -0400 To: atom-syntax@imc.org From: James Robertson <jarober@gosmalltalk.com> Subject: Re: Shipping Atom products prematurely In-Reply-To: <1092769057.4122552127119@www.hutteman.com> References: <20040817182527.77434.qmail@web41209.mail.yahoo.com> <1092769057.4122552127119@www.hutteman.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> > >I can see only two alternatives to this: >1) make all subsequent versions of Atom backwards compatible with Atom 0.3 (I >think most here would agree this would be a bad idea) That would be bad how, exactly? >2) put a recommendation in any pre-1.0 atom spec stating that, while >experimenting is allowed (or even encouraged), authors should also publish a >feed using a more mature and stable format (i.e. one of the RSS dialects) for >use by aggregators that do no support this particular pre-1.0 Atom version yet >(or not anymore, once a new version is published). Once Google shipped Atom 0.3 feeds, this option ceased to exist. <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView jarober@gosmalltalk.com From owner-atom-syntax@mail.imc.org Tue Aug 17 15:35:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10586 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:35:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJJGKq091888; Tue, 17 Aug 2004 12:19:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HJJGp3091887; Tue, 17 Aug 2004 12:19:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJJF4M091880 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 12:19:16 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1Bx9UL-0005KG-BW; Tue, 17 Aug 2004 19:19:17 +0000 Message-ID: <41225A32.9050504@franklinmint.fm> Date: Tue, 17 Aug 2004 15:19:14 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: luke@hutteman.com CC: atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> <1092762927.41223d2fa1233@www.hutteman.com> <p06110446bd47f9e2a532@[10.20.30.249]> <1092768387.4122528370504@www.hutteman.com> In-Reply-To: <1092768387.4122528370504@www.hutteman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit luke@hutteman.com wrote: > Quoting Paul Hoffman / IMC <phoffman@imc.org>: > >>Until the final, standardized version, the documents will make it >>clear that implementers should only implement for internal use. If we >>find some implementers creating feeds from pre-standards IETF drafts, >>a bit of quick public education can probably fix the problem. > > > hmm... seems to me that "a bit of quick public education" might be overdue > here... quite a few Atom 0.3 implementations out there that aren't internal... > Paul is suggesting that we do this for people publishing from the ietf draft specs (post-0.3). As I understand it, the roadmap looks like this: Atom 0.3 draft-ietf-atompub-00 draft-ietf-atompub-01 ... draft-ietf-atompub-NN Atom 1.0 I believe that the goal is for there not to be another widely implemented draft until Last Call. Perhaps the chairs and secretary should explain this in more detail (I believe they have, I can't remember where to look). My question is whether Mark N's proposal includes Atom 0.3. It's too late for that, IMHO. Aggregator authors have told us that consumers consider clients that don't support Atom 0.3 to be broken. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 17 15:37:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10813 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:37:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJMmeL092110; Tue, 17 Aug 2004 12:22:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HJMmRd092109; Tue, 17 Aug 2004 12:22:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJMmSc092086 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 12:22:48 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <200408171922460130012npte>; Tue, 17 Aug 2004 19:22:47 +0000 Date: Tue, 17 Aug 2004 13:22:45 -0600 Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <1092769057.4122552127119@www.hutteman.com> Message-Id: <D1569847-F082-11D8-94D3-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Tuesday, August 17, 2004, at 12:57 PM, luke@hutteman.com wrote: > 2) put a recommendation in any pre-1.0 atom spec stating that, while > experimenting is allowed (or even encouraged), authors should also > publish a > feed using a more mature and stable format (i.e. one of the RSS > dialects) for > use by aggregators that do no support this particular pre-1.0 Atom > version yet > (or not anymore, once a new version is published). I suspect that some developers who are anxious to get on the buzzword-compliance bandwagon may need to be tossed a bone to keep them placated till 1.0 arrives. For example, we might put a note like those that have been suggested on the rest of the pre-1.0 drafts, with a note that if someone simply MUST deploy Atom now and will not be dissuaded, we recommend that they implement version 0.3 and NOT any other pre-1.0 version, and that they prepare to drop 0.3 soon once 1.0 comes out. On the plus side, if we can't dissuade people completely from deploying support for pre-1.0 versions, maybe we can at least get people to limit themselves to ONE pre-release version. On the minus side, this might be misconstrued as an official stamp of approval on deployment of 0.3 if we don't do a good job of making it clear that it's not. No matter what we do, I think we're going to have 0.3 floating around for a while. From owner-atom-syntax@mail.imc.org Tue Aug 17 15:47:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11327 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:47:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJdRpu093055; Tue, 17 Aug 2004 12:39:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HJdRYC093054; Tue, 17 Aug 2004 12:39:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode03.zonnet.nl ([62.58.50.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJdQv0093030 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 12:39:26 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 11679 invoked by uid 10); 17 Aug 2004 19:38:54 -0000 Received: (vexira-qq 11672-4F945838 invoked from network) 17 Aug 2004 21:38:54 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender <mail@annevankesteren.nl>) by postbode03.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 17 Aug 2004 19:38:54 -0000 Message-ID: <41225EC9.4020000@annevankesteren.nl> Date: Tue, 17 Aug 2004 21:38:49 +0200 From: Anne van Kesteren <mail@annevankesteren.nl> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Graham <dtcd@mac.com> CC: Mark Nottingham <mnot@mnot.net>, Atom WG <atom-syntax@imc.org> Subject: Re: Shipping Atom products prematurely References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> In-Reply-To: <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.4; VDF: 6.27.0.17; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit >> As such, I think the WG should proactively contact vendors of consumer >> products and services and ask them to refrain from integrating Atom >> support until it's done. They have the best of intentions by >> supporting Atom, but may do more harm than good by accelerating the >> adoption of it prematurely. > > Isn't the first step getting atomenabled.org taken off air? Ehmm.. People are aware *a lot* of sites have Atom feeds? Blogger uses it as default. WordPress has it by default. MoveableType has it by default. NucleusCMS/BLOG:CMS has it by default. I believe Google news groups have Atom feeds. You want to say the Atom project is temporary over? I guess the Atom WG should try to finalyse as soon as possible and as correct as possible and don't waste time in endless discussions about dates and other personal preferences. (That all imho, of course.) -- Anne van Kesteren <http://annevankesteren.nl/> From owner-atom-syntax@mail.imc.org Tue Aug 17 15:49:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11420 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:49:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJWWq7092699; Tue, 17 Aug 2004 12:32:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HJWWEi092698; Tue, 17 Aug 2004 12:32:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJWW0H092690 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 12:32:32 -0700 (PDT) (envelope-from jarober@gosmalltalk.com) Received: from victoria (pcp01741172pcs.howard01.md.comcast.net[68.54.83.139]) by comcast.net (sccrmhc11) with ESMTP id <20040817193230011004rhp2e>; Tue, 17 Aug 2004 19:32:31 +0000 Received: from james2.gosmalltalk.com (james [10.55.1.103]) by victoria (8.11.0/8.11.0) with ESMTP id i7HJWUR18768 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 15:32:30 -0400 Message-Id: <6.1.2.0.2.20040817153013.02843428@www.gosmalltalk.com> X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 17 Aug 2004 15:32:04 -0400 To: atom-syntax@imc.org From: James Robertson <jarober@gosmalltalk.com> Subject: Re: Shipping Atom products prematurely In-Reply-To: <p06110446bd47f9e2a532@[10.20.30.249]> References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> <1092762927.41223d2fa1233@www.hutteman.com> <p06110446bd47f9e2a532@[10.20.30.249]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> >Any vendor who implements from anything other than the final IETF standard >will have a host of problems interoperating in the future. IETF documents >expire after six months, and are usually unavailable within nine months. >So, if someone releases code based on draft-ietf-atompub-format-07.txt, >that document will soon become unavailable, meaning that someone else >cannot determine how to interop with it in the future. Umm, no. I can tell you that for me, supporting a new rev of Atom (or RSS) is the addition of one class into my system. No modifications to other code, and no impact on other code either. All that matters to me is whether interim versions get used. If they get used, then I have to support them. If they don't, then I don't. Words from the IETF are meaningless - it's what actually takes place that matters >Of course, the RFCs we produce will live forever. You can still find RFC 1 >on IMP software at <ftp://ftp.rfc-editor.org/in-notes/rfc1.txt> 35 years later. > >The Atompub WG *will* have proper and understandable versioning in both >the format and protocol before we are finished. > >Until the final, standardized version, the documents will make it clear >that implementers should only implement for internal use. If we find some >implementers creating feeds from pre-standards IETF drafts, a bit of quick >public education can probably fix the problem. > >--Paul Hoffman, Director >--Internet Mail Consortium > > <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView jarober@gosmalltalk.com From owner-atom-syntax@mail.imc.org Tue Aug 17 15:52:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11571 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 15:52:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJhOZQ093335; Tue, 17 Aug 2004 12:43:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HJhOZW093334; Tue, 17 Aug 2004 12:43:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HJhMqo093325; Tue, 17 Aug 2004 12:43:22 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p06110449bd480ff0d0a0@[10.20.30.249]> In-Reply-To: <1092768387.4122528370504@www.hutteman.com> References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> <1092762927.41223d2fa1233@www.hutteman.com> <p06110446bd47f9e2a532@[10.20.30.249]> <1092768387.4122528370504@www.hutteman.com> Date: Tue, 17 Aug 2004 12:43:15 -0700 To: luke@hutteman.com, atom-syntax@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 2:46 PM -0400 8/17/04, luke@hutteman.com wrote: >I've seen a few Atom 0.2 feeds in the wild, but agree that these are >very sparse >and therefore not much of a problem. Atom started getting much more popular >with 0.3 though, so I expect this to become a bigger problem when the next >version is published. Do you mean the first two Internet Drafts, or the final RFC? > > Until the final, standardized version, the documents will make it >> clear that implementers should only implement for internal use. If we > > find some implementers creating feeds from pre-standards IETF drafts, > > a bit of quick public education can probably fix the problem. > >hmm... seems to me that "a bit of quick public education" might be overdue >here... quite a few Atom 0.3 implementations out there that aren't internal... There is some really-hard-to-miss education in the drafts. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 17 16:36:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13664 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 16:36:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HKMGmw095328; Tue, 17 Aug 2004 13:22:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HKMGr5095327; Tue, 17 Aug 2004 13:22:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HKMEc9095321 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 13:22:15 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p06110450bd4815711b0c@[10.20.30.249]> In-Reply-To: <41225A32.9050504@franklinmint.fm> References: <20040817145622.84732.qmail@web41213.mail.yahoo.com> <1092762927.41223d2fa1233@www.hutteman.com> <p06110446bd47f9e2a532@[10.20.30.249]> <1092768387.4122528370504@www.hutteman.com> <41225A32.9050504@franklinmint.fm> Date: Tue, 17 Aug 2004 13:22:01 -0700 To: atom-syntax@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 3:19 PM -0400 8/17/04, Robert Sayre wrote: >As I understand it, the roadmap looks like this: > >Atom 0.3 >draft-ietf-atompub-00 >draft-ietf-atompub-01 >... >draft-ietf-atompub-NN >Atom 1.0 Yes. >I believe that the goal is for there not to be another widely >implemented draft until Last Call. No! We do not want wide implementation until after the IESG approves of draft-ietf-atompub-NN. There are many reasons for this: - Having a dozen set of eyes with lots of protocol experience looking at the document often uncovers actual protocol errors that we just never noticed because we got too used to them. - They may say "this doesn't work the IETF way, but it would be fine if you change it to that way" and we make the change - They sometimes ask a really good question about a particular feature, and in our answering the question we fix something unclear in the document, and in doing that we find two pre-implementers who disagree, and we need to decide what "we" "really meant". When the IESG sends -NN to the RFC Editor for publication, -NN becomes 1.0. We can even have a special half-step in there where the IESG says "we're fine with this draft except for the cruddy version number wording, so change that and off it goes." The editors do the final change and everyone knows that the new draft is Really It. > Perhaps the chairs and secretary should explain this in more detail >(I believe they have, I can't remember where to look). It's not well-documented anywhere. This might go into a new version of the Tao of the IETF, of which I am also co-author... >My question is whether Mark N's proposal includes Atom 0.3. It's too >late for that, IMHO. Aggregator authors have told us that consumers >consider clients that don't support Atom 0.3 to be broken. Fully agree. We all have to live with the fact that Atom 0.3 is akin to RSS 0.9. Eventually, almost no creator software will emit it, but it will probably live on in reading software forever. The Internet is littered with such cases. For instance, most web browsers can still read Gopher sites even though almost no one has created one in over seven years. Atom 0.3 had its purpose: it gave people something to talk about and look at before the Atom community came into the IETF. It showed that things were possible. It showed where there was massive disagreement. Atom 0.3 will exist forever, just like RSS 0.9 will. It is not hard for us to prevent anything before Atom 1.0 to be deployed. The drafts are really clear about not implementing them. The folks on this list are really clear that we don't want them implemented. So far, we have been 100% successful in not having the drafts be implemented in an externally-visible way, and I don't see why that will stop until we tell the world "We think it's fully baked, and the IESG thinks it is fully baked, and we now have a reasonable version number and/or namespace, so now you can implement." --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 17 17:33:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15721 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 17:33:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HLANTY098676; Tue, 17 Aug 2004 14:10:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HLANMC098675; Tue, 17 Aug 2004 14:10:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HLANf9098669 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 14:10:23 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7HLAPkN020517; Tue, 17 Aug 2004 14:10:25 -0700 (PDT) Received: from [10.232.7.124] ([17.255.240.30]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i7HLAMth008501; Tue, 17 Aug 2004 14:10:24 -0700 (PDT) In-Reply-To: <41225EC9.4020000@annevankesteren.nl> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-653188926; protocol="application/pkcs7-signature" Message-Id: <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> Cc: Mark Nottingham <mnot@mnot.net>, Sam Ruby <rubys@intertwingly.net>, Atom WG <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Date: Tue, 17 Aug 2004 16:10:21 -0500 To: Anne van Kesteren <mail@annevankesteren.nl> X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --Apple-Mail-2-653188926 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 17 Aug 2004, at 2:38 pm, Anne van Kesteren wrote: > You want to say the Atom project is temporary over? No. My point was that there's a website run by the Secretary of this very Working Group that explicitly advocates people implement Atom support in shipping products. Would someone care to explain? Graham --Apple-Mail-2-653188926 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODE3MjExMDIyWjAjBgkqhkiG9w0BCQQxFgQUWPMsjOCRlWXUFwlFz8B8Anfd 7DwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEANCJmVj3vqZe24Dfdw116Cmuy oS0p5pSLkb0LPP3JIsNJSNoPiE5pgsqJ6DOOSqY0+UOYduePc70Ft8Yko7GpWLCp6S2AB3CQuUoA wHrC1n3bxrA0vtr00m6s0/BDFWKLGNPjdzVod+PiPe6zeir7VZsmt63s6WCIy6g0tGJOFtnG/IPC kIAlAkxA63gKtwarq5lZ0/yPN0SJYYJcU9VTCl/gLnMncHsXOtO7n4GLbuBm1fuHMFHg1nAMwNYT eVWUEYL9vD6JkGVYUZu4lfL0JMziuxmp0zZFXuL/dobIa3tFYabLelGgRw1+X8ijpdSH/uuVGbdN VkB6XIEtV85GxwAAAAAAAA== --Apple-Mail-2-653188926-- From owner-atom-syntax@mail.imc.org Tue Aug 17 17:38:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16276 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 17:38:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HLQn5w099597; Tue, 17 Aug 2004 14:26:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HLQnUC099596; Tue, 17 Aug 2004 14:26:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HLQm18099570 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 14:26:49 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 56866 messnum 1985336 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 17 Aug 2004 21:26:47 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail10.svc.cra.dublin.eircom.net (qp 56866) with SMTP; 17 Aug 2004 21:26:47 -0000 Message-ID: <41227813.4010402@dehora.net> Date: Tue, 17 Aug 2004 22:26:43 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817184234.74995.qmail@web41212.mail.yahoo.com> In-Reply-To: <20040817184234.74995.qmail@web41212.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > The point is that forcing users to upgrade their > aggregator to read a feed they could read just fine a > day before results in pissed off users and I provided > a real-world example. > > I'm not sure where a claim that Mark Pilgrim is > obligated to Dare Obasanjo arises from the above > statement. Seems obvious enough to me, unless you care to weasel word from a position of complete pedantry. People have been "forced" to upgrade their aggregators since forever as I recall. Atom 0.3 is nothing new or special here. Perhaps you have a useful point to make, but I can't see it. Again, what do you suggest should be done?. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 17 18:24:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20000 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 18:24:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HM8FAB003237; Tue, 17 Aug 2004 15:08:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HM8Fo9003236; Tue, 17 Aug 2004 15:08:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HM8El7003227 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 15:08:14 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040817220814.41382.qmail@web41203.mail.yahoo.com> Received: from [207.46.228.98] by web41203.mail.yahoo.com via HTTP; Tue, 17 Aug 2004 15:08:14 PDT Date: Tue, 17 Aug 2004 15:08:14 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Shipping Atom products prematurely To: "Bill_de_hÓra" <bill@dehora.net>, atom-syntax@imc.org In-Reply-To: <41227813.4010402@dehora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Bill_de_hÓra <bill@dehora.net> wrote: > > Seems obvious enough to me, unless you care to > weasel word from a > position of complete pedantry. People have been > "forced" to upgrade > their aggregators since forever as I recall. Please name these incidents. When have websites the large readerships abandoned an existing syndication format and forced users to upgrade their clients in recent memory let alone being commonplace as you imply? >Atom > 0.3 is nothing new > or special here. Perhaps you have a useful point to > make, but I > can't see it. Again, what do you suggest should be > done?. The point is painfully obvious. If your sites use Atom 0.3 you have to decide how you plan to react when Atom 1.0 ships and how this will affect consumers of your syndication feeds. Based on the fact that some people were lauding Google and others when they chose Atom 0.3 as the sole syndication format for certain sites even though Atom was not final makes it clear that not everyone involved carefully considered the cost of that decision. This discussion thread describes the cost of these decisions from the folks who'll be on the front line when sites like Blogger break users; the aggregator authors. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 17 18:37:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20557 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 18:37:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HMNwSC004087; Tue, 17 Aug 2004 15:23:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HMNwex004086; Tue, 17 Aug 2004 15:23:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HMNvQU004079 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 15:23:57 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BxCMx-0001Jd-7Z; Tue, 17 Aug 2004 22:23:51 +0000 Message-ID: <41228576.1090602@franklinmint.fm> Date: Tue, 17 Aug 2004 18:23:50 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham <dtcd@mac.com> CC: Anne van Kesteren <mail@annevankesteren.nl>, Mark Nottingham <mnot@mnot.net>, Sam Ruby <rubys@intertwingly.net>, Atom WG <atom-syntax@imc.org> Subject: atomenabled.org References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> In-Reply-To: <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Graham wrote: > On 17 Aug 2004, at 2:38 pm, Anne van Kesteren wrote: > >> You want to say the Atom project is temporary over? > > > No. My point was that there's a website run by the Secretary of this > very Working Group that explicitly advocates people implement Atom > support in shipping products. Would someone care to explain? atomenabled.org shows people the following: draft-nottingham-atom-format-02 draft-gregorio-09 aka Atom 0.3. The site doesn't even mention the IETF drafts. You *ship* a product with Atom support. Says so in big letters right there on the homepage. I doubt you plan on removing that capability. There's nothing wrong with implementing Atom 0.3. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 17 18:52:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21627 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 18:52:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HMibCC005479; Tue, 17 Aug 2004 15:44:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HMibvr005478; Tue, 17 Aug 2004 15:44:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HMiahJ005466 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 15:44:37 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 79884 messnum 5067621 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 17 Aug 2004 22:44:36 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail04.svc.cra.dublin.eircom.net (qp 79884) with SMTP; 17 Aug 2004 22:44:36 -0000 Message-ID: <41228A50.6060008@dehora.net> Date: Tue, 17 Aug 2004 23:44:32 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817220814.41382.qmail@web41203.mail.yahoo.com> In-Reply-To: <20040817220814.41382.qmail@web41203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > Please name these incidents. I've upgraded or chnaged readers to read feeds as new formats appeared. Was I the only one? I doubt it. Am I the only exhibiting multiple feed formats? I doubt it. > When have websites the > large readerships abandoned an existing syndication > format and forced users to upgrade their clients in > recent memory let alone being commonplace as you > imply? You're mixing matters to suit your argument. Is this a rant against Google's/Blogger's choices, a rant against atom version control, a rant against new formats a rant against Pilgrim, all the above? I'm lost. > The point is painfully obvious. Perhaps to you, certainly I'm none the wiser via this extended diatribe. > If your sites use Atom > 0.3 you have to decide how you plan to react when Atom > 1.0 ships and how this will affect consumers of your > syndication feeds. I'll add a new feed as I did for other RSSes. Which one people subscribe is their own business, whether I cut any of those feeds is my business. > [ex-cathedra snipped] What do suggest should be done? cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 17 18:57:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21814 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 18:57:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HMi2wn005438; Tue, 17 Aug 2004 15:44:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HMi2GW005437; Tue, 17 Aug 2004 15:44:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HMi1F9005427 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 15:44:01 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BxCgS-0005bB-S2; Tue, 17 Aug 2004 22:44:01 +0000 Message-ID: <41228A30.3050104@franklinmint.fm> Date: Tue, 17 Aug 2004 18:44:00 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: =?ISO-8859-1?Q?Bill=5Fde=5Fh=D3ra?= <bill@dehora.net>, atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely References: <20040817220814.41382.qmail@web41203.mail.yahoo.com> In-Reply-To: <20040817220814.41382.qmail@web41203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > The point is painfully obvious. If your sites use Atom > 0.3 you have to decide how you plan to react when Atom > 1.0 ships and how this will affect consumers of your > syndication feeds. > Do you have an idea other than redirecting after a suitable period of time? What would you like to see producers do? > > This discussion thread describes the cost of > these decisions from the folks who'll be on the front > line when sites like Blogger break users; the > aggregator authors. This discussion is growing melodramatic. In the event that a site "breaks users", don't you think the site would hear about it as well? Their authors must be using an aggregator. Everyone is "on the front line". Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 17 19:05:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22046 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 19:05:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HMltN8005684; Tue, 17 Aug 2004 15:47:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HMltFi005683; Tue, 17 Aug 2004 15:47:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7HMltsa005675 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 15:47:55 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040817224755.96224.qmail@web41207.mail.yahoo.com> Received: from [207.46.228.16] by web41207.mail.yahoo.com via HTTP; Tue, 17 Aug 2004 15:47:55 PDT Date: Tue, 17 Aug 2004 15:47:55 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Shipping Atom products prematurely To: Robert Sayre <mint@franklinmint.fm> Cc: "Bill_de_hÓra" <bill@dehora.net>, atom-syntax@imc.org In-Reply-To: <41228A30.3050104@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Robert Sayre <mint@franklinmint.fm> wrote: > > Do you have an idea other than redirecting after a > suitable period of > time? What would you like to see producers do? I'd like producers to wait until Atom 1.0 until they deploy Atom. If they already have deployed previous versions redirecting after a suitable period of time is a decent solution. Some people will be inconvenienced but it can't be helped at this point. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 17 19:49:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23482 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 19:49:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HNasOB008296; Tue, 17 Aug 2004 16:36:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HNasax008295; Tue, 17 Aug 2004 16:36:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HNanR9008289 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 16:36:51 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p0611045fbd4846f1b597@[10.20.30.249]> In-Reply-To: <20040817224755.96224.qmail@web41207.mail.yahoo.com> References: <20040817224755.96224.qmail@web41207.mail.yahoo.com> Date: Tue, 17 Aug 2004 16:36:48 -0700 To: Atom WG <atom-syntax@imc.org> From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 3:47 PM -0700 8/17/04, Dare Obasanjo wrote: >I'd like producers to wait until Atom 1.0 until they >deploy Atom. If they already have deployed previous >versions redirecting after a suitable period of time >is a decent solution. Some people will be >inconvenienced but it can't be helped at this point. +1 --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 17 19:51:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23513 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 19:51:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HNi7KM008600; Tue, 17 Aug 2004 16:44:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HNi7bN008599; Tue, 17 Aug 2004 16:44:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HNi6ei008592 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 16:44:06 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7HNiCil015766 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 17:44:12 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2M00GES79N9Y@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 17 Aug 2004 17:44:11 -0600 (MDT) Received: from [192.168.1.100] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2M00CQB79LE1@mail.sun.net> for atom-syntax@imc.org; Tue, 17 Aug 2004 17:44:11 -0600 (MDT) Date: Tue, 17 Aug 2004 16:44:18 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Shipping Atom products prematurely In-reply-to: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> To: Mark Nottingham <mnot@mnot.net> Cc: Atom WG <atom-syntax@imc.org> Message-id: <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Aug 15, 2004, at 3:21 PM, Mark Nottingham wrote: > I've just changed the old, pre-WG drafts that I host on mnot.net to > clearly state that they're not to be implemented, and are superseded > by the work here. Thanks Mark, and thanks for raising the issue here, I thought the discussion was really useful. There seems fairly widespread agreement that: 1. Atom 0.3 is out in the wild, implementations of it will live as long as the gopher support still there in modern browsers. It's been useful. 2. We should try really hard to keep any interim versions this side of 1.0 from escaping into the wild [modulo the fact that the release of v1.0 of anything is a punctuated, jerky, non-atomic event]; so far we're doing OK on this. 3. Atom 1.0 is probably going to be substantially incompatible with 0.3 in several respects and that's OK. 4. We should hurry up and get this done. If anyone observes any leakage of post-0.3 pre-1.0 versions, please shout loudly and continuously and we'll see what community pressure can do. When 1.0 ships, we should all join together and use the (considerable) power of our public voices to get the world to start switching over. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 17 20:06:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23948 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 20:06:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HNvNf3009501; Tue, 17 Aug 2004 16:57:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HNvNpt009499; Tue, 17 Aug 2004 16:57:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HNvM9X009491 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 16:57:22 -0700 (PDT) (envelope-from jarober@gosmalltalk.com) Received: from victoria (pcp01741172pcs.howard01.md.comcast.net[68.54.83.139]) by comcast.net (sccrmhc13) with ESMTP id <2004081723572201600d7kdje>; Tue, 17 Aug 2004 23:57:22 +0000 Received: from james2.gosmalltalk.com (james [10.55.1.103]) by victoria (8.11.0/8.11.0) with ESMTP id i7HNvMR19221 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 19:57:22 -0400 Message-Id: <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 17 Aug 2004 19:57:01 -0400 To: atom-syntax@imc.org From: James Robertson <jarober@gosmalltalk.com> Subject: Re: Shipping Atom products prematurely In-Reply-To: <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> As a content producer, what advantage would there be in switching to Atom 1.0? Given that every aggregator supports (and will continue to support) RSS 2.0, and given that I want to make it as easy as possible to be read, what good reason would there be for me to switch? Heck, what good reasons would there be for adding Atom 1.0? This isn't intended to be a negative comment, actually. It would be useful to have an answer to these questions - because the easiest thing to do as a content producer is exactly what I do now.... >If anyone observes any leakage of post-0.3 pre-1.0 versions, please shout >loudly and continuously and we'll see what community pressure can >do. When 1.0 ships, we should all join together and use the >(considerable) power of our public voices to get the world to start >switching over. > > -Tim > > <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView jarober@gosmalltalk.com From owner-atom-syntax@mail.imc.org Tue Aug 17 20:23:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24560 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 20:23:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0BIOA010152; Tue, 17 Aug 2004 17:11:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I0BI3u010151; Tue, 17 Aug 2004 17:11:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0BIQU010137 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 17:11:18 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id RAA08417 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 17:11:14 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id RAA21885 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 17:11:14 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Tue, 17 Aug 2004 17:11:13 -0700 Received: from adsl-64-166-133-244.dsl.snfc21.pacbell.net (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2M00HX88IN4Y@shazam.verity.com> for atom-syntax@imc.org; Tue, 17 Aug 2004 17:11:13 -0700 (PDT) Date: Tue, 17 Aug 2004 17:11:11 -0700 From: Walter Underwood <wunder@verity.com> X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy Subject: Re: Shipping Atom products prematurely In-reply-to: <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> To: Atom WG <atom-syntax@imc.org> Message-id: <9570A9FA8090D4CA789D4D25@adsl-64-166-133-244.dsl.snfc21.pacbell.net> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT --On Tuesday, August 17, 2004 4:44 PM -0700 Tim Bray <Tim.Bray@Sun.COM> wrote: > > If anyone observes any leakage of post-0.3 pre-1.0 versions, please shout loudly and continuously and we'll see what community pressure can do. When 1.0 ships, we should all join together and use the (considerable) power of our public voices to get the world to start switching over. Again, I suggest that the drafts specify <atom-draft> (or <feed-draft>) to identify any such leakage. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 17 20:36:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25440 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 20:36:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0Hpxe010839; Tue, 17 Aug 2004 17:17:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I0HpWv010838; Tue, 17 Aug 2004 17:17:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0Ho2H010832 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 17:17:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7I0Hoao019451; Tue, 17 Aug 2004 17:17:50 -0700 (PDT) Received: from [10.232.7.124] ([17.255.240.30]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i7I0HP7u002656; Tue, 17 Aug 2004 17:17:31 -0700 (PDT) In-Reply-To: <41228576.1090602@franklinmint.fm> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> <41228576.1090602@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-664411492; protocol="application/pkcs7-signature" Message-Id: <FAF480AE-F0AB-11D8-817E-000A95DC3D90@mac.com> Cc: Sam Ruby <rubys@intertwingly.net>, Atom WG <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: atomenabled.org Date: Tue, 17 Aug 2004 19:17:23 -0500 To: Robert Sayre <mint@franklinmint.fm> X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --Apple-Mail-3-664411492 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 17 Aug 2004, at 5:23 pm, Robert Sayre wrote: > You *ship* a product with Atom support. Says so in big letters right > there on the homepage. I doubt you plan on removing that capability. > > There's nothing wrong with implementing Atom 0.3. Mark Nottingham, at the start of this thread: "I've just changed the old, pre-WG drafts ... to clearly state that they're not to be implemented ... One of the things that drove me to do this is the increasing incidence of vendors shipping products and services that "support" Atom, even though it's clearly marked as a pre-draft" Once again, why is atomenabled.org still online if we don't want people implementing? And Robert, are you seriously saying there's nothing wrong with encouraging people to write new implementations of Atom 0.3 today? (I wrote my Atom 0.3 implementation at least in part because of that website, if it counts for anything) Graham --Apple-Mail-3-664411492 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODE4MDAxNzI0WjAjBgkqhkiG9w0BCQQxFgQU6zyjyVjFHoUgqTgAJAgUSR3M x+MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAJmXKZr5RL4exxXUJSDu48/61 E1Vsj/YLPqekIXYL39qgcazR5pdZnFVD24GJu+cSJY2qCRekl1HUcGgbp6SxzG3DOvbPV2i/6Nhg AHiqlmcdnduDxj/XtGecJiMLbuzaFgEnKevrOx1sItkKpT+gon21j7s1/gf1xMikl7JT0+sOw//Q SUvc7gUm6rlMB9RBZRq0ogFVd7VqwrZtV5txT7lSJYKRixG6Lz8CcHzrVN2l4N/k5K1C4e2N3Q2B Hs/w0Hxo47wIw2DBA85yDiL4g16jWxXkWXpf+lyaYAqPl3TIoZZM5bMXAH6DicpX7y+oioU68rn1 sCYZp/eg2+VklQAAAAAAAA== --Apple-Mail-3-664411492-- From owner-atom-syntax@mail.imc.org Tue Aug 17 20:54:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27985 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 20:54:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0eVvF012292; Tue, 17 Aug 2004 17:40:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I0eVlW012291; Tue, 17 Aug 2004 17:40:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0eU2p012285 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 17:40:30 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.212]) by mail.mnot.net (Postfix) with ESMTP id D390E727D; Tue, 17 Aug 2004 17:40:35 -0700 (PDT) In-Reply-To: <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <377B0FB2-F0AF-11D8-9BC6-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham <mnot@mnot.net> X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})<LET/,:$!V Z2a`,}:,!$ZW-^s0JO}F[(71D38:rzvK|7DB;VA|@`]uggG,{@2UuA$XpM;r|[[w/bQ&P4 zW"FB+p{u)CCjiRx=c)-S=c>B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Motivating Content Producers Date: Tue, 17 Aug 2004 17:40:34 -0700 To: James Robertson <jarober@gosmalltalk.com> X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit This question has been on my mind, too; thanks for pointing it out. We need to have a clear idea of what's going to compel people to switch to Atom. I would put forth that the most valuable thing -- from content producers' standpoints -- is predictability of behaviour in aggregators and other consumers, so they *know* how their feed will appear. Not cosmetically, but functionally. This is why I think issues like managing feed state are so important. The actual functionality we provide is less critical than the consistency of its use across different consumers. This doesn't mean that all aggregators have to look the same and offer the same bland view of the data; it's just that the data must be reproduced faithfully. For example, if aggregator one keeps a history of items in the feed, and it marks different ones as 'new' than aggregator two does, there's clearly a problem. I think we have a unique opportunity here, in that a great majority of the vendors interested in writing products that consume Atom are at the table and willing to work together. This can translate into a clear win over existing technology if we can agree on what an aggregator is, what a feed is, and how they interact*. This, IMO, is what we should be working towards. The alternative is just as you say -- a repeat of RSS with a few changes that only people here care about. Cheers, * There is a tension here, in that IMO we shoudn't say that Atom is ONLY for aggregators; that's why I've consistently advocated building a logically separate profile just for the common aggregator/blog situation. On Aug 17, 2004, at 4:57 PM, James Robertson wrote: > As a content producer, what advantage would there be in switching to > Atom 1.0? Given that every aggregator supports (and will continue to > support) RSS 2.0, and given that I want to make it as easy as possible > to be read, what good reason would there be for me to switch? Heck, > what good reasons would there be for adding Atom 1.0? > > This isn't intended to be a negative comment, actually. It would be > useful to have an answer to these questions - because the easiest > thing to do as a content producer is exactly what I do now.... -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 17 21:00:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28682 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 21:00:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0qJcB013229; Tue, 17 Aug 2004 17:52:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I0qJYW013228; Tue, 17 Aug 2004 17:52:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0qIZI013222 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 17:52:18 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BxEgh-0000Bs-50; Wed, 18 Aug 2004 00:52:23 +0000 Message-ID: <4122A844.303@franklinmint.fm> Date: Tue, 17 Aug 2004 20:52:20 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham <dtcd@mac.com> CC: Sam Ruby <rubys@intertwingly.net>, Atom WG <atom-syntax@imc.org> Subject: Re: atomenabled.org References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> <41228576.1090602@franklinmint.fm> <FAF480AE-F0AB-11D8-817E-000A95DC3D90@mac.com> In-Reply-To: <FAF480AE-F0AB-11D8-817E-000A95DC3D90@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Graham wrote: > On 17 Aug 2004, at 5:23 pm, Robert Sayre wrote: > >> You *ship* a product with Atom support. Says so in big letters right >> there on the homepage. I doubt you plan on removing that capability. >> >> There's nothing wrong with implementing Atom 0.3. > > > Mark Nottingham, at the start of this thread: > "I've just changed the old, pre-WG drafts ... to clearly state that > they're not to be implemented ... One of the things that drove me to do > this is the increasing incidence of vendors shipping products and > services that "support" Atom, even though it's clearly marked as a > pre-draft" http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html So the deadline has passed for writing an Atom 0.3 parser? I don't get it. There are millions of Atom 0.3 feeds out there, and implementors aren't supposed to support them because of a retroactive decision by the editor based on his perception of their mass-marketness? Yeah, I dunno... > > Once again, why is atomenabled.org still online if we don't want people > implementing? And Robert, are you seriously saying there's nothing wrong > with encouraging people to write new implementations of Atom 0.3 today? > Let's assume a producer wants to migrate to Atom 1.0 eventually. It doesn't matter what they choose now. They will still face migration issues. Besides Atom 0.3 is more stable than RSS 2[0]. Meanwhile, I'm still seeing "<cite>" in the titles of my RSS feeds from The Register. Thunderbird 0.8 and Mac OS X 10.4/Safari 2.0 are going to ship with Atom 0.3 support. Who wants to write the email that tells them they have to support fewer feeds than Shrook, RSS Bandit, FeedDemon, NNW, etc? Robert Sayre [0] http://blogs.law.harvard.edu/tech/rssChangeNotes From owner-atom-syntax@mail.imc.org Tue Aug 17 21:11:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29456 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 21:11:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I105Wi013706; Tue, 17 Aug 2004 18:00:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I105jW013705; Tue, 17 Aug 2004 18:00:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I105Bf013693 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:00:05 -0700 (PDT) (envelope-from jarober@gosmalltalk.com) Received: from victoria (pcp01741172pcs.howard01.md.comcast.net[68.54.83.139]) by comcast.net (sccrmhc13) with ESMTP id <2004081801000501600d6qi6e>; Wed, 18 Aug 2004 01:00:05 +0000 Received: from james2.gosmalltalk.com (james [10.55.1.103]) by victoria (8.11.0/8.11.0) with ESMTP id i7I104R19375 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 21:00:05 -0400 Message-Id: <6.1.2.0.2.20040817205856.0262f8b8@www.gosmalltalk.com> X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 17 Aug 2004 20:59:44 -0400 To: atom-syntax@imc.org From: James Robertson <jarober@gosmalltalk.com> Subject: Re: Shipping Atom products prematurely In-Reply-To: <p06110462bd485896d86e@[10.20.30.249]> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> <p06110462bd485896d86e@[10.20.30.249]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 08:52 PM 8/17/2004, you wrote: >At 7:57 PM -0400 8/17/04, James Robertson wrote: >>As a content producer, what advantage would there be in switching to Atom >>1.0? > >When we get close to finishing, we'll have a better answer. For now, there >is nothing we can say definitively because we don't know what the final >specs will look like. That's a pretty lame answer, to be honest. What advantages would you expect there to be? >--Paul Hoffman, Director >--Internet Mail Consortium > <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView jarober@gosmalltalk.com From owner-atom-syntax@mail.imc.org Tue Aug 17 21:19:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29938 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 21:19:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0qT79013243; Tue, 17 Aug 2004 17:52:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I0qTBB013242; Tue, 17 Aug 2004 17:52:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I0qQst013236; Tue, 17 Aug 2004 17:52:26 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p06110462bd485896d86e@[10.20.30.249]> In-Reply-To: <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> Date: Tue, 17 Aug 2004 17:52:25 -0700 To: James Robertson <jarober@gosmalltalk.com>, atom-syntax@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 7:57 PM -0400 8/17/04, James Robertson wrote: >As a content producer, what advantage would there be in switching to Atom 1.0? When we get close to finishing, we'll have a better answer. For now, there is nothing we can say definitively because we don't know what the final specs will look like. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 17 21:19:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29956 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 21:19:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I12PTA013859; Tue, 17 Aug 2004 18:02:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I12P8v013858; Tue, 17 Aug 2004 18:02:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I12O49013841 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:02:24 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 5B5624F0B2; Tue, 17 Aug 2004 21:02:30 -0400 (EDT) Date: Tue, 17 Aug 2004 21:02:30 -0400 From: Dan Brickley <danbri@w3.org> To: Mark Nottingham <mnot@mnot.net> Cc: James Robertson <jarober@gosmalltalk.com>, atom-syntax@imc.org Subject: Re: Motivating Content Producers Message-ID: <20040818010229.GA12422@homer.w3.org> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> <377B0FB2-F0AF-11D8-9BC6-000A95BD86C0@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <377B0FB2-F0AF-11D8-9BC6-000A95BD86C0@mnot.net> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> * Mark Nottingham <mnot@mnot.net> [2004-08-17 17:40-0700] > > This question has been on my mind, too; thanks for pointing it out. > > We need to have a clear idea of what's going to compel people to switch > to Atom. I would put forth that the most valuable thing -- from content > producers' standpoints -- is predictability of behaviour in aggregators > and other consumers, so they *know* how their feed will appear. Not > cosmetically, but functionally. This is an interesting discussion to have. I'm interested to hear whether the AtomPub WG expect an Atom 1.0 document format to be able to do everything that RSS 1.0 can do (and more, presumably). I've tended to see Atom as being optimised for weblogging use cases, at the possible expense of the general-purpose extensibility that RSS 1.0 enjoys. But maybe it'll do both...? dan From owner-atom-syntax@mail.imc.org Tue Aug 17 21:37:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00507 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 21:37:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I1ROpd015972; Tue, 17 Aug 2004 18:27:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I1ROVw015971; Tue, 17 Aug 2004 18:27:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I1RNm7015952 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:27:23 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so159724rnk for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:27:22 -0700 (PDT) Received: by 10.38.102.41 with SMTP id z41mr243067rnb; Tue, 17 Aug 2004 18:27:22 -0700 (PDT) Message-ID: <14be96d304081718277f55ebb@mail.gmail.com> Date: Tue, 17 Aug 2004 21:27:22 -0400 From: Mark Pilgrim <pilgrim@gmail.com> Reply-To: Mark Pilgrim <pilgrim@gmail.com> To: Graham <dtcd@mac.com> Subject: Re: atomenabled.org Cc: Robert Sayre <mint@franklinmint.fm>, Sam Ruby <rubys@intertwingly.net>, Atom WG <atom-syntax@imc.org> In-Reply-To: <FAF480AE-F0AB-11D8-817E-000A95DC3D90@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> <41228576.1090602@franklinmint.fm> <FAF480AE-F0AB-11D8-817E-000A95DC3D90@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Tue, 17 Aug 2004 19:17:23 -0500, Graham <dtcd@mac.com> wrote: > Mark Nottingham, at the start of this thread: > "I've just changed the old, pre-WG drafts ... to clearly state that > they're not to be implemented ... > > Once again, why is atomenabled.org still online if we don't want people > implementing? Obviously, Mark Nottingham has gone off on his own here, and modified his pre-draft in place nine months after it was first issued. Honestly, these kind of shenanigans are what we rightly bitched about when we saw the same sort of behavior in the RSS community. It's one of the main reasons we sought stewardship in a stable standards organization -- because individual spec maintainers can't be trusted. I'm not saying Mark should be removed from editorship, but if you were inclined to make a list, I would expect you would add this to it. Meanwhile, Mark has no influence over atomenabled.org, which is primarily a marketing site and is maintained by early adopter vendors. AFAIK, that site has no official relationship to the Atom Working Group, so I expect they can and will say whatever they damn well please. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 17 21:40:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00642 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 21:40:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I1TtKh016269; Tue, 17 Aug 2004 18:29:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I1TtPr016268; Tue, 17 Aug 2004 18:29:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I1TtoG016262 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:29:55 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.212]) by mail.mnot.net (Postfix) with ESMTP id 6547D727D for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:30:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <4122A844.303@franklinmint.fm> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> <41228576.1090602@franklinmint.fm> <FAF480AE-F0AB-11D8-817E-000A95DC3D90@mac.com> <4122A844.303@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1FD5B5EB-F0B6-11D8-9BC6-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham <mnot@mnot.net> X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})<LET/,:$!V Z2a`,}:,!$ZW-^s0JO}F[(71D38:rzvK|7DB;VA|@`]uggG,{@2UuA$XpM;r|[[w/bQ&P4 zW"FB+p{u)CCjiRx=c)-S=c>B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: atomenabled.org Date: Tue, 17 Aug 2004 18:30:01 -0700 To: "'Atom WG'" <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Aug 17, 2004, at 5:52 PM, Robert Sayre wrote: > I don't get it. There are millions of Atom 0.3 feeds out there, and > implementors aren't supposed to support them because of a retroactive > decision by the editor based on his perception of their > mass-marketness? Yeah, I dunno... Implementers can do what they like; nothing can constrain their activity, unless they break the law or a contract. As the owner of mnot.net, I can do literally anything I like with that draft. Note that I implicitly own the copyright on itif push comes to shove. Scared? Anybody relying on that spec should be. Let's not even mention that it's massively under-specified, and I'd imagine that it manages to contradict itself too. Does this situation sound familiar? It should. Will it stop some implementers from using it? Probably not, but why should they be encouraged to persist in doing so? The whole reason we're here is to do this work under the auspices of the IETF, so it has the stability, change control, buy-in, completeness and technical review that implies. Let's not jump the gun. Regards, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 17 21:44:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00752 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 21:44:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I1X1Xm016628; Tue, 17 Aug 2004 18:33:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I1X1fi016627; Tue, 17 Aug 2004 18:33:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I1X0o5016609 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:33:00 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so240634rnk for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:33:01 -0700 (PDT) Received: by 10.38.102.11 with SMTP id z11mr242395rnb; Tue, 17 Aug 2004 18:33:01 -0700 (PDT) Message-ID: <14be96d304081718331676bd41@mail.gmail.com> Date: Tue, 17 Aug 2004 21:33:01 -0400 From: Mark Pilgrim <pilgrim@gmail.com> Reply-To: Mark Pilgrim <pilgrim@gmail.com> To: Graham <dtcd@mac.com> Subject: Re: Cc: Anne van Kesteren <mail@annevankesteren.nl>, Mark Nottingham <mnot@mnot.net>, Sam Ruby <rubys@intertwingly.net>, Atom WG <atom-syntax@imc.org> In-Reply-To: <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Tue, 17 Aug 2004 16:10:21 -0500, Graham <dtcd@mac.com> wrote: > On 17 Aug 2004, at 2:38 pm, Anne van Kesteren wrote: > > > You want to say the Atom project is temporary over? > > No. My point was that there's a website run by the Secretary of this > very Working Group that explicitly advocates people implement Atom > support in shipping products. Would someone care to explain? Sam and I "run" http://feedvalidator.org/ which explicitly "validates" Atom 0.3 feeds against Mark Nottingham's 0.3 pre-draft. Should we shut this down too? By the way, in case you hadn't noticed, I also "run" several sites of a personal nature on the same server as the feed validator. Obviously these reflect poorly on the working group and should be shut down ASAP. Also, I have from time to time been less than speedy in my denials of accusations that I kill kittens. It's obviously a BigCo conspiracy. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 17 22:05:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01386 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 22:04:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I1luch018353; Tue, 17 Aug 2004 18:47:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I1luNH018352; Tue, 17 Aug 2004 18:47:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I1ltVm018346 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 18:47:56 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BxFYX-00089s-8r; Wed, 18 Aug 2004 01:48:01 +0000 Message-ID: <4122B54E.9090609@franklinmint.fm> Date: Tue, 17 Aug 2004 21:47:58 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham <mnot@mnot.net> CC: "'Atom WG'" <atom-syntax@imc.org> Subject: Re: atomenabled.org References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> <41228576.1090602@franklinmint.fm> <FAF480AE-F0AB-11D8-817E-000A95DC3D90@mac.com> <4122A844.303@franklinmint.fm> <1FD5B5EB-F0B6-11D8-9BC6-000A95BD86C0@mnot.net> In-Reply-To: <1FD5B5EB-F0B6-11D8-9BC6-000A95BD86C0@mnot.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > As the owner of mnot.net, I can do literally anything I like with that > draft. Note that I implicitly own the copyright on itif push comes to > shove. Scared? No. Delete it. Let's see 410 at work! Is the status of the Atom 0.3 draft on-topic for this list or not? Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 17 22:09:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01504 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 22:09:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I20H79019912; Tue, 17 Aug 2004 19:00:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I20HdU019911; Tue, 17 Aug 2004 19:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I20G7X019903 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 19:00:16 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so160808rnk for <atom-syntax@imc.org>; Tue, 17 Aug 2004 19:00:17 -0700 (PDT) Received: by 10.38.102.41 with SMTP id z41mr249767rnb; Tue, 17 Aug 2004 19:00:17 -0700 (PDT) Message-ID: <14be96d3040817190029313799@mail.gmail.com> Date: Tue, 17 Aug 2004 22:00:17 -0400 From: Mark Pilgrim <pilgrim@gmail.com> Reply-To: Mark Pilgrim <pilgrim@gmail.com> To: Mark Nottingham <mnot@mnot.net> Subject: Re: atomenabled.org Cc: Atom WG <atom-syntax@imc.org> In-Reply-To: <1FD5B5EB-F0B6-11D8-9BC6-000A95BD86C0@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <72C5F9C9-F081-11D8-817E-000A95DC3D90@mac.com> <41225EC9.4020000@annevankesteren.nl> <D9C8D602-F091-11D8-817E-000A95DC3D90@mac.com> <41228576.1090602@franklinmint.fm> <FAF480AE-F0AB-11D8-817E-000A95DC3D90@mac.com> <4122A844.303@franklinmint.fm> <1FD5B5EB-F0B6-11D8-9BC6-000A95BD86C0@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Tue, 17 Aug 2004 18:30:01 -0700, Mark Nottingham <mnot@mnot.net> wrote: > As the owner of mnot.net, I can do literally anything I like with that > draft. Note that I implicitly own the copyright on itif push comes to > shove. If someone were making a list of reasons to remove you from editorship, I would definitely expect them to add that statement to the list too. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 17 22:31:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02364 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 22:31:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I2NL4d022474; Tue, 17 Aug 2004 19:23:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I2NLWs022473; Tue, 17 Aug 2004 19:23:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta201-rme.xtra.co.nz (mta201-rme.xtra.co.nz [210.86.15.144]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I2NK1r022462 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 19:23:20 -0700 (PDT) (envelope-from angus@twinhelix.com) Received: from mta7-rme.xtra.co.nz ([210.86.15.140]) by mta201-rme.xtra.co.nz with ESMTP id <20040818022313.WJXO5635.mta201-rme.xtra.co.nz@mta7-rme.xtra.co.nz> for <atom-syntax@imc.org>; Wed, 18 Aug 2004 14:23:13 +1200 Received: from nirvana ([222.152.134.183]) by mta7-rme.xtra.co.nz with SMTP id <20040818022313.STCG9663.mta7-rme.xtra.co.nz@nirvana> for <atom-syntax@imc.org>; Wed, 18 Aug 2004 14:23:13 +1200 Message-ID: <002a01c484ca$4b051120$eb01a8c0@nirvana> From: "Angus Turnbull" <angus@twinhelix.com> To: <atom-syntax@imc.org> Subject: Distributed comment/post authorisation proposal Date: Wed, 18 Aug 2004 14:23:02 +1200 Organization: TwinHelix Designs - http://www.twinhelix.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7I2NK1r022468 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Greetings all, Since this email is rather lengthy, I'll begin with a brief synopsis. I think the ATOM API is a good place to implement an idea I've been considering for a while: distributed blog comment/post authorisation. Basically, all existing post authorisation API schemes assume that a poster has an account with a username and password on the server hosting the blog. However, it would be possible to add functionality to host an authorisation server as a CGI script on your own domain (or a provider of your choice) that would allow you to post comments/articles on other blogs, authenticated as yourself, without giving personal information to the blog owner. Think of Microsoft Passport done via an open-standard API for blogging. If this is (a) interesting, (b) possible and (c) novel, I've outlined my ideas below. Also, thanks to Anne van Kesteren for taking an initial glance at it and suggesting that it be posted here! Regards, Angus Turnbull http://www.twinhelix.com -------- Currently, a page that accepts user content has a <LINK> tag in the header for autodiscovery of Atom services. As such, it should be simple to implement an authorisation scheme like this involving two fictional users: 1) Andy visits Bob's blog at www.bob.com, and intends to leave a comment. Andy does not have an account on Bob's blog, nor does he wish to sign up for an account on Bob's server, as he does not trust Bob with his password(s). However, Andy dislikes people impersonating him online, and wishes to use some kind of authentication mechanism so Bob's readers know it's Andy that is posting. 2) Andy has a CGI script installed on his server (or a trusted hosting provider) implementing this authentication system. He loads the script in his browser, configures it with a password, and drags a bookmarklet like this onto his browser toolbar: javascript:window.open('http://www.andy.com/atom-auth.cgi?page='+location.href);void(0); 3) Andy visits Bob's blog to leave a comment, and clicks the bookmarklet. Non-JavaScript capable useragents would have to manually open up the correct CGI script via their bookmarks, and cut/paste Bob's blog URI into a form field there. (Ideas for better accessibility are welcome; perhaps a feature of the post-comment fields on the target blog...?) 4) Andy's server either remembers him via a cookie, or he logs in normally, or by some other form of authorisation. 5) Andy fills in his comment and hits "Post" on his own server. (Alternatively, steps 3-5 could be performed by Andy's Atom client software submitting his post to his own server using the existing Atom API authorisation scheme, but with the eventual destination URI specified as Bob's blog. That would be a simple implementation issue; the client would generate a "reply to this post" button/link after compliant posts it had syndicated). 6) The interesting part begins. Andy's webserver acts as an Atom client and contacts Bob's Atom server, submitting an HTTP POST similar to an existing Atom authentication request, containing its own URI alongside the standard <author>, <content> and nonce+date, but no hash. Andy's server retains this information. 7) Bob's server receives an incoming request from an unknown IP address. It retrieves and stores the post data, and closes the HTTP connection. 8) Bob's server opens a new HTTP connection to the URI contained in the POST, which is the CGI script on Andy's server. It calculates a hash consisting of: SHA1(nonce+date+comment content), and posts the hash and Andy's <author> details back to the Andy's server using a defined Atom API. Note that "comment content" would be specified as having all newlines as "\n" characters, to ensure hash consistency. 9) Andy's server receives an incoming request, and checks that the supplied hash matches its own record of Andy's user details and nonce+date+comment. It returns a success/failure code to Bob's server using a defined format. This is to foil man-in-the-middle attacks. 10) Bob's weblog, assuming step 9 returned successfully, displays Andy's post and username, and the authentication URL used (http://www.andy.com/atom-auth.cgi), so visitors know it's really Andy that has commented. This could probably be simplified or corrected a little, and perhaps more run of it over the existing Atom API, but the extensions required would be pretty trivial. The advantages of this system: * Anyone could set up an authorisation server of their own, never have to sign up at hundreds of different weblog service providers, and yet be reliably authenticated as themselves. * Bob cannot use Andy's account details to post as Andy on other weblogs, something that is possible under the current "create-an-account everywhere" paradigm with a less-than-honest webmaster and poster who duplicates passwords. * It would be easy for anyone to start up a trusted authorisation service and give away accounts, with easy setup procedures, so this could catch on with non-technical users who don't really know what a CGI script or Atom client is. * You could extend a remote authorisation mechanism with all sorts of cool syndication-based hacks. Disadvantages: * Six Apart and Blogger already have their own authentication systems and are unlikely to want to give up their sweet proprietary lock-in goodness, but it's not a perfect world. * It would be vulnerable to people signing up for similar-looking domains like www.4ndy.com and setting up authentication servers on them; I can't think of a workaround there. * Untrustworthy sites could simply post "You all suck, this comment is by So-and-so and authorised at his/her correct URL". There's nothing really to stop that either, unless Andy's CGI software retains and publishes a list of sites to which he's contributed; that's just an implementation issue. If you've read this far, what do you think? Is it workable and/or desirable? Should we work on nailing together some kind of proposal for the ATOM Wiki? I don't mind if anyone takes this idea and runs with it, by the way. Cheers - Angus. From owner-atom-syntax@mail.imc.org Tue Aug 17 22:54:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03477 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 22:54:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I2iBco025675; Tue, 17 Aug 2004 19:44:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I2iBRi025674; Tue, 17 Aug 2004 19:44:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I2i8Co025659; Tue, 17 Aug 2004 19:44:09 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: <p06110470bd48710891ee@[10.20.30.249]> In-Reply-To: <6.1.2.0.2.20040817205856.0262f8b8@www.gosmalltalk.com> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> <p06110462bd485896d86e@[10.20.30.249]> <6.1.2.0.2.20040817205856.0262f8b8@www.gosmalltalk.com> Date: Tue, 17 Aug 2004 19:43:55 -0700 To: James Robertson <jarober@gosmalltalk.com>, atom-syntax@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Shipping Atom products prematurely Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 8:59 PM -0400 8/17/04, James Robertson wrote: >That's a pretty lame answer, to be honest. What advantages would >you expect there to be? Wow, an engineer is *asking* for a marketing shpiel. :-) - We expect it to be tigher and better-defined than previous RSSs so that there will be better long-term interoperability. - We expect there to be standard features like publishing and autodiscovery that will help Atom users in ways that are unavailable in previous RSSs. - We expect that the extensibility will be cleaner and better defined so that small markets will be able to use Atom easier than previous RSSs. None of that might spin your beanie. One big reason many of us are working on Atom is that we believe that RSSish syndication can become a major communication mechanism for literally decades to come (look at RFC 822 and MIME, for instance). If that is true, it should have the most polished, most reviewed, and clearest spec possible. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 17 23:35:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05482 for <atompub-archive@lists.ietf.org>; Tue, 17 Aug 2004 23:35:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I3OE6A030916; Tue, 17 Aug 2004 20:24:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I3OEDP030915; Tue, 17 Aug 2004 20:24:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I3ODEP030909 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 20:24:13 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7I3OK53013267 for <atom-syntax@imc.org>; Tue, 17 Aug 2004 21:24:20 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2M00H66HGJ4S@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 17 Aug 2004 21:24:20 -0600 (MDT) Received: from [192.168.1.100] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2M00CQVHGIE1@mail.sun.net> for atom-syntax@imc.org; Tue, 17 Aug 2004 21:24:19 -0600 (MDT) Date: Tue, 17 Aug 2004 20:24:28 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Motivating Content Producers In-reply-to: <377B0FB2-F0AF-11D8-9BC6-000A95BD86C0@mnot.net> To: Mark Nottingham <mnot@mnot.net> Cc: James Robertson <jarober@gosmalltalk.com>, atom-syntax@imc.org Message-id: <1CB59F80-F0C6-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> <377B0FB2-F0AF-11D8-9BC6-000A95BD86C0@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Aug 17, 2004, at 5:40 PM, Mark Nottingham wrote: > We need to have a clear idea of what's going to compel people to > switch to Atom. I would put forth that the most valuable thing -- from > content producers' standpoints -- is predictability of behaviour in > aggregators and other consumers, so they *know* how their feed will > appear. Not cosmetically, but functionally. I have three real pain points around RSS: 1. I see way too many dupe articles 2. The markup escaping is too easy to get wrong 3. The APIs are kludgy and have interoperability problems I think Atom has a chance to make all those pain points go away and provide a compelling incentive for content providers to move to Atom. Of course, this will only reveal the next set of irritating pain points, but that's life. -Tim From owner-atom-syntax@mail.imc.org Wed Aug 18 04:01:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16412 for <atompub-archive@lists.ietf.org>; Wed, 18 Aug 2004 04:01:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I7lRET000479; Wed, 18 Aug 2004 00:47:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I7lR0t000475; Wed, 18 Aug 2004 00:47:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I7lO0b000454; Wed, 18 Aug 2004 00:47:26 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 427094F1AD; Wed, 18 Aug 2004 03:47:24 -0400 (EDT) Date: Wed, 18 Aug 2004 03:47:24 -0400 From: Dan Brickley <danbri@w3.org> To: Paul Hoffman / IMC <phoffman@imc.org> Cc: James Robertson <jarober@gosmalltalk.com>, atom-syntax@imc.org Subject: Re: Shipping Atom products prematurely Message-ID: <20040818074720.GA24078@homer.w3.org> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> <p06110462bd485896d86e@[10.20.30.249]> <6.1.2.0.2.20040817205856.0262f8b8@www.gosmalltalk.com> <p06110470bd48710891ee@[10.20.30.249]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <p06110470bd48710891ee@[10.20.30.249]> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> * Paul Hoffman / IMC <phoffman@imc.org> [2004-08-17 19:43-0700] > - We expect that the extensibility will be cleaner and better defined > so that small markets will be able to use Atom easier than previous > RSSs. Really? That'd be great, but I've not seen much evidence that the WG takes that view. I'm comparing with RSS 1.0's RDF/XML-based extensibility framework; the other flavours don't really have one, except for RSS 2.0's "use namespaces and you're on your own". Extensibility comes at a price, and designing something cleaner and better than RDF will be an interesting endeavour. Finding a clean and syntactically graceful way of mapping _into_ RDF also comes at a price, as does (of course) simply using full RDF/XML syntax. The pre-IETF Atom community decided some time ago that they didn't find RDF/XML an attractive proposition, which I guess means we're going the route of defining an extensibility model that is somehow better than RSS 1.0's. Hmm so what were the key benefits of RDF extensibility in RSS 1.0? - (fairly) predictable XML notation; RSS 1.0 defined a profile of the RDF/XML syntax, so that namespace-extended feeds all shared a basic structure. (rather than allowing all RDF's syntactic variations). - Supported free combination of independently developed descriptive vocabulary (manifested as RDF/XML-based namespaces). RSS 1.0 feeds can carry extra markup describing things in the world beyond syndication, such as people, places, movies, bank accounts. Element names in the markup correspond to classes (categories) and properties (fields, relations etc) defined by any RDF vocabulary that proves useful. - The external vocabularies a feed draws upon do not need to be defined with RSS 1.0 (or Atom or newsfeed syndication) in mind. Or be tightly coordinated amongst themselves. There is a tightly-defined model and simple-minded (additive) model for explaining how these independent namespaces interact when deployed together. What were the problems / drawbacks with RSS 1.0's RDF extensibility? - explaining the XML-level constraints on markup structures amounted to the need to present a mini-tutorial on RDF's syntax rules, since RSS 1.0 used RDF's standard XML encoding. This involves unenviable tasks like explaing RDF's "striped" XML style (see http://www.w3.org/2001/10/stripes/ ), and trying to summarise the rules for when you use "rdf:about=" versus "rdf:resource=" attributes. - when RSS 1.0 shipped (4 years ago) there weren't many RDF vocabularies, software libraries were less mature, and the RDF specs hadn't gone through the RDFCore cleanup (which finished Feb'04). Sites like http://www.schemaweb.info/ show that there are a growing number of vocabularies, but many are still a bit drafty. - RSS 1.0 was perhaps a little too minimalist, forcing people to use extensions for things that a broader syndication-oriented vocab could have included in a more generous core. - The only widely used extension for carrying hypertext content in RSS 1.0 was 'content:encoded', which somewhat opts-out of the XML world. RDF in 2000 was a bit vague on how to deal with namespaces, xml:base, xml:lang andther canonicalisation issues relating to "literal XML" content. (addressed in Feb'04 specs) - the blogging use case (which dominated RSS deployment and evangelism) didn't have as much to gain from a powerful extensibility framework as those apps which sometimes get called 'synthetic feeds'. > None of that might spin your beanie. One big reason many of us are > working on Atom is that we believe that RSSish syndication can become > a major communication mechanism for literally decades to come (look > at RFC 822 and MIME, for instance). If that is true, it should have > the most polished, most reviewed, and clearest spec possible. Yes, that's what draws me to RSS 1.0 and its siblings. One lesson from the non-blogging use cases (job adverts, movie listings, bank account feeds, etc.) that get some of us enthused is that the most interesting bits of the markup are those which use (possibly various) non-RSS namespaces. RSS is the least interesting, and simplest, part of the document. I think the recently announced "Nature" RSS 1.0 feeds might repay study, as a way of thinking about the tradeoffs around AtomPub's extensibility goals. See http://www.nature.com/rss/ There are feeds there from scientific journals, and for job listings in the sciences. The extensions used are both useful, and evocative. They immediately suggest further extension ideas. eg. http://www.nature.com/nrc/journal/v4/n8/rss.rdf [[ <item rdf:about="http://dx.doi.org/10.1038/nrc1424"> <title>TUMOUR VIRUSES: A genetic switch http://dx.doi.org/10.1038/nrc1424 Kristine Novak TUMOUR VIRUSES: A genetic switch Kristine Novak doi:10.1038/nrc1424 Nature Reviews Cancer 4, 572 (2004) 2004-08-01 Nature Reviews Cancer 2004-08-01 4 8 Highlights 572 ]] or, more interesting: http://www.nature.com/naturejobs/jobs/biologicalsciences.rdf [[ University of Sheffield: Research Associate http://naturejobs.nature.com/texis/jobsearch/details.html?id=411109c54a01090&lookid=nature Research Associate, University of Sheffield, Sheffield, United Kingdom. Posted on 4 August 2004. University of Sheffield Research Associate Sheffield United Kingdom 2004-08-04 2004-09-02 ]] So already we're talking about the syndicating online representations of articles, digital rights, page numbers, authors, cancer, jobs, cities, locations and expiry dates for job applications. All of those things are (a) beyond the immediate and future scope of the AtomPub group (b) described in different levels of detail by different parties for different purposes. Eg. jobs are based in places; they have associated skills, which might be picked out in cross-domain subject schemes or in domain specific details; places have lat/long info, which can be modelled in painful detail or very crudely. XML description here is a task without end, because we're trying to create a marketplace where it is possibly for increasingly rich descriptions to be mixed together in as sane a fashion as possible. I'd be interested to take this http://www.nature.com/naturejobs/jobs/biologicalsciences.rdf feed as a test for AtomPub's extensibility goals. Would we hope to do a cleaner/better job than RSS 1.0 here. Perhaps in the future, scientifically minded job hunters will be able to go do a search on jobs in their particular speciality and see the results using geographically-oriented tools. I'd love to see Atom become a transport for all this... cheers, Dan From owner-atom-syntax@mail.imc.org Wed Aug 18 04:41:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18426 for ; Wed, 18 Aug 2004 04:41:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I8OqCj011571; Wed, 18 Aug 2004 01:24:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I8OqJZ011570; Wed, 18 Aug 2004 01:24:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7I8OnAr011521 for ; Wed, 18 Aug 2004 01:24:51 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040818082445.62583.qmail@web41202.mail.yahoo.com> Received: from [24.18.136.49] by web41202.mail.yahoo.com via HTTP; Wed, 18 Aug 2004 01:24:45 PDT Date: Wed, 18 Aug 2004 01:24:45 -0700 (PDT) From: Dare Obasanjo Subject: Extensibility in Syndication formats To: Dan Brickley , Paul Hoffman / IMC Cc: James Robertson , atom-syntax@imc.org In-Reply-To: <20040818074720.GA24078@homer.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Dan Brickley wrote: > > I'm comparing with RSS 1.0's > RDF/XML-based > extensibility framework; the other flavours don't > really have one, > except for RSS 2.0's "use namespaces and you're on > your own". I am suspicious of any claims that RDF buys you more extensibility than using XML and namespaces in practice. See http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=5b31837c-49cc-4d1d-9f14-fd25df8b54f2 for details. But let's go on... > The pre-IETF > Atom community decided some time ago that they > didn't find RDF/XML > an attractive proposition, which I guess means we're > going the route of > defining an extensibility model that is somehow > better than RSS 1.0's. > > Hmm so what were the key benefits of RDF > extensibility in RSS 1.0? > > - (fairly) predictable XML notation; RSS 1.0 > defined a profile of the > RDF/XML syntax, so that namespace-extended feeds > all shared a > basic structure. (rather than allowing all RDF's > syntactic > variations). How is this practically useful? The fact that an extension will show up as single elements with simple content or as elements with attributes and complex contents doesn't bring my application any closer to understanding them when encountered in the wild. > - Supported free combination of independently > developed descriptive > vocabulary (manifested as RDF/XML-based > namespaces). RSS 1.0 feeds > can carry extra markup describing things in the > world beyond > syndication, such as people, places, movies, bank > accounts. Element > names in the markup correspond to classes > (categories) and properties > (fields, relations etc) defined by any RDF > vocabulary that proves > useful. I see this in RSS 2.0 as well. > - The external vocabularies a feed draws upon do > not need to be defined > with RSS 1.0 (or Atom or newsfeed syndication) in > mind. Or be tightly > coordinated amongst themselves. There is a > tightly-defined model and > simple-minded (additive) model for explaining how > these independent > namespaces interact when deployed together. I see this in RSS 2.0 as well. > What were the problems / drawbacks with RSS 1.0's > RDF extensibility? > > - explaining the XML-level constraints on markup > structures amounted > to the need to present a mini-tutorial on RDF's > syntax rules, since > RSS 1.0 used RDF's standard XML encoding. This > involves unenviable > tasks like explaing RDF's "striped" XML style > (see > http://www.w3.org/2001/10/stripes/ ), and trying > to summarise the > rules for when you use "rdf:about=" versus > "rdf:resource=" > attributes. > > - when RSS 1.0 shipped (4 years ago) there weren't > many RDF > vocabularies, software libraries were less > mature, and the RDF > specs hadn't gone through the RDFCore cleanup > (which finished Feb'04). > Sites like http://www.schemaweb.info/ show that > there are a > growing number of vocabularies, but many are > still a bit drafty. > > - RSS 1.0 was perhaps a little too minimalist, > forcing people to use > extensions for things that a broader > syndication-oriented vocab > could have included in a more generous core. > > - The only widely used extension for carrying > hypertext content in > RSS 1.0 was 'content:encoded', which somewhat > opts-out of > the XML world. RDF in 2000 was a bit vague on how > to deal with > namespaces, xml:base, xml:lang andther > canonicalisation issues > relating to "literal XML" content. (addressed in > Feb'04 specs) > > - the blogging use case (which dominated RSS > deployment and evangelism) > didn't have as much to gain from a powerful > extensibility framework > as those apps which sometimes get called > 'synthetic feeds'. So far you have listed a bunch of drawbacks of the RDF based approach used by RSS 1.0 and none of the benefits that haven't been seen using just XML and namespaces in RSS 2.0. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 18 05:52:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22657 for ; Wed, 18 Aug 2004 05:52:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I9iaoL051569; Wed, 18 Aug 2004 02:44:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I9iaJp051568; Wed, 18 Aug 2004 02:44:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I9iZ7u051446 for ; Wed, 18 Aug 2004 02:44:35 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 72302 invoked by uid 17064); 18 Aug 2004 09:44:26 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.4.182]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Aug 2004 09:44:26 -0000 In-Reply-To: <37EA4202-EECB-11D8-A370-000A95D9FA7A@bblfish.net> References: <37EA4202-EECB-11D8-A370-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2D9525FA-F0FB-11D8-BAC6-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: rdfweb-dev@vapours.rdfweb.org, bloged From: Henry Story Subject: Re: Atom-FOAF Date: Wed, 18 Aug 2004 11:44:19 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Here are some of my own thoughts concerning this [1] work: - How is this an improvement over RSS1.0. I am very new to RDF, RSS and blogging, and have not yet had much time to look at what the RSS1.0 community has come up with. Perhaps I am just (badly) re-inventing the wheel. I would love feedback from that area on how they think one could improve on their work, and the pitfalls one should avoid. Perhaps there is an RSS1.0 meeting point I should send this to. - clearly there is a lot of overlap with Dublin Core. It would be interesting to make these obvious by stating the equality relations between the properties I have defined and the Dublin Core ones in the Atom.owl file. - Should the foaf:Agent class be accessed directly, as it is in the example, or should one interpose an interface class, say atom:Agent, as Danny Ayers does in his Atom-OWL[2] work from which mine is derived. An interface class would be one that specifies the minimal requirements. If one were to do this, then presumably somebody could still end up with something directly referencing foaf:Agent, but I suppose they would have to import some ontology that makes the equality explicit. What is the best way to deal with importing such rules? Anyway as a side comment I have to say that this RDF thing is really easy to get a grip on. With tools such as Protege [3], from Stanford University, writing object oriented RDF is a breeze. Languages such as N3 make reading RDF as easy as reading the morning newspaper. And it really feels good to have something that is based not only on such widely adopted standards as XML, but also supported by the full mathematical infrastructure of set theory and logic [4]. I love power tools, and we have not found anything much better than mathematics yet. It is only by building on the shoulder of giants that we can hope to go any further. I think that the view from up on Tim Berner's Lee's shoulder is going to be pretty awesome. Henry On 15 Aug 2004, at 16:55, Henry Story wrote: > > I have written out a full description with a lot of illustrations on > how to FOAFify Atom [1]. The description is written out as a blog > which is using the format it is advocating to back it up. So it is > both a description and a proof of concept. > > I see this being useful to the foaf, atom, and bloged communities for > different reasons: > - for the atom community it could bring bring some ontological > insight, and lead to clarifications - mapping always do that. > - for the foaf community, I suggest this as an opening into the > blogging space > - for bloged, the blog editor I am working on, this will be useful > at the very > least to help nail down the needed data structures, though I hope to > use it both as > an internal and external data-structure. > > I look very much forward to any criticism. This document is the result > of many such criticisms, for which I am very thankful. > > Henry Story [1] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html [2] http://semtext.org/atom/index.html [3] http://protege.stanford.edu/ [4] http://www.w3.org/TR/rdf-mt/ From owner-atom-syntax@mail.imc.org Wed Aug 18 05:59:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22956 for ; Wed, 18 Aug 2004 05:59:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I9lPE6054011; Wed, 18 Aug 2004 02:47:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I9lPJu054010; Wed, 18 Aug 2004 02:47:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I9lPuV053935 for ; Wed, 18 Aug 2004 02:47:25 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so150833rnb for ; Wed, 18 Aug 2004 02:47:20 -0700 (PDT) Received: by 10.38.206.39 with SMTP id d39mr1385290rng; Wed, 18 Aug 2004 02:47:20 -0700 (PDT) Message-ID: <1f2ed5cd04081802471becfcd7@mail.gmail.com> Date: Wed, 18 Aug 2004 11:47:20 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Extensibility in Syndication formats Cc: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org In-Reply-To: <20040818082445.62583.qmail@web41202.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040818082445.62583.qmail@web41202.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I am suspicious of any claims that RDF buys you more > extensibility than using XML and namespaces in > practice. (I expect Dan will respond - still, here's another couple of cents) I'm a little surprised to find that you still hold this opinion, but ok, by way of example. Say you wanted your RSS entry to describe a project. In RSS 2.0 you might have something like: http://example.org My Project My Project http://example.org/home In RSS 1.0 it might look like: My Project ... My Project If the consumer understands the project vocabulary, then full communication can take place with either version. However, assume the consumer knows nothing about the project extension. If the consumer understands RDF/XML syntax, then from the RSS 1.0 version it can determine that: 1. the item resource is an instance of the class doap:Project 2. the item has a literal property, doap:name with the value "My Project" 3. the item has a property with a resource as it's value, the URI being "http://example.org/home" 4. that doap:Project is an rdfs:Class 5. that doap:name is an rdf:Property with a domain including doap:Project 6. that doap:homepage is an rdf:Property with a domain including doap:Project 7. that doap:homepage is an rdf:Property (and a few other bits) If the consumer is aware of the RDF Schema for doap, then it also has access to other information, for example that doap:name is an rdfs:subPropertyOf rdf-schema#label". This could be used to decide how to render the value for display. If the consumer understands RSS 2.0, XML and namespaces, then it still understands absolutely *nothing* about the project information, not even that it applies to the same item. Partial understanding is only one advantage, another big one is that RSS/RDF vocabularies can be mixed and matched with impunity and still carry that partial understanding (if fact, combined partial understanding of all the parts). On the other hand, mixtures of arbitrary combinations of RSS 2.0-based extensions are undefined, and there is nothing to prevent conflicts in their interpretation (namespaces separate the terms, but conflicts may appear at a higher level in the app). See also: http://www.xml.com/pub/a/2003/07/23/extendingrss.html Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Aug 18 06:04:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23304 for ; Wed, 18 Aug 2004 06:04:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I9irTk051759; Wed, 18 Aug 2004 02:44:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I9ir3v051758; Wed, 18 Aug 2004 02:44:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7I9iqhC051662 for ; Wed, 18 Aug 2004 02:44:52 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 21994 messnum 3927937 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 18 Aug 2004 09:41:21 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail08.svc.cra.dublin.eircom.net (qp 21994) with SMTP; 18 Aug 2004 09:41:21 -0000 Message-ID: <4123243F.1090601@dehora.net> Date: Wed, 18 Aug 2004 10:41:19 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818082445.62583.qmail@web41202.mail.yahoo.com> In-Reply-To: <20040818082445.62583.qmail@web41202.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > How is this practically useful? The fact that an > extension will show up as single elements with simple > content or as elements with attributes and complex > contents doesn't bring my application any closer to > understanding them when encountered in the wild. Speaking as an avowed and somewhat loudmouthed RDF cynic. It's useful because one can add new data items to markup with breaking existing code downstream. Whether you want to add code to meaningfully process those data items is another matter. You seem to be deliberatly mixing those two things up, or perhaps you don't understand the difference. In my experience XML+namespaces doesn't provide anything like that. Quite the opposite it's sufficiently fragile to almsot assure breakage down stream and down time, so much so entire communities are encouraged to figure out a sensible means to layer extensibility onto schema driven XML documents, something that we'll be doing here soon enough no doubt. Much of this fragility I see as I suspect is a direct result of people believing that XML+namespaces have some magical properties of extensibilty and getting bitten later on. > So far you have listed a bunch of drawbacks of the RDF > based approach used by RSS 1.0 and none of the > benefits that haven't been seen using just XML and > namespaces in RSS 2.0. That's makes so little sense it's not even wrong. When it comes to extensibility or flexibility in markup, making these sorts of claims around "just XML and namespaces" is bunk. For example, I've read yours and others useful articles and papers on extensibility. Yet that's not just XML and namespaces, that's an entire added semantics on top "of just XMl and namespaces" *and* schemata. So really you're comparing RDF/RSS1.0 with "just XML and Namespaces" and schema and a lot of other articulated processes and constraints. We here, already have XML+namespaces for Atom, remind me again why we need a model extensilbilty? In OO terms, the difference between RSS1.0 and all the others is very like the difference between programming with reflection/hashmaps and programming with domain specific objects. Both have their uses, bth have their drawbacks. The primary tension in my experience there is a balancing act to conduct between the flexbility provided by something like RDF versus the clarity of domain specific markup. Raw RDF is not neccessarily comprehensible with respect to a 'domain model', raw XML+Namespaces is not neccessarily flexible with respect to 'change'. I suspect it helps to have tried both approaches rather than simply looking at them and opining to appreciate this. cheers Bill From owner-atom-syntax@mail.imc.org Wed Aug 18 07:27:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28217 for ; Wed, 18 Aug 2004 07:27:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IBCvah003679; Wed, 18 Aug 2004 04:12:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IBCuQ5003677; Wed, 18 Aug 2004 04:12:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IBCrEv003644 for ; Wed, 18 Aug 2004 04:12:54 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7IBEb1O001370; Wed, 18 Aug 2004 07:14:38 -0400 Message-ID: <412339B0.4020900@intertwingly.net> Date: Wed, 18 Aug 2004 07:12:48 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pier Fumagalli CC: atom-syntax@imc.org Subject: Re: Syndication of updates and deletions of content References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pier Fumagalli wrote: > > Now, how would I syndicate the fact that a resource is gone away? Of > course I won't include in the syndication feed all of our content (more > than 100k articles), but only what happened in the (let's say) past 24 > hours. But how can a subscriber to my Atom feed know whether a resource > is simply not included, or it was actually removed? What do you think that subscribers MAY do with this information? SHOULD? MUST? Are there ever cases where a publisher MUST or SHOULD include deleted information in a feed? > I thought about having an "entry" structured in this way: > > > Microsoft lists apps affected by XP SP2 > http://www.vnunet.com/news/1157398 > > 2004-08-17T08:29:29Z > > > but I'm not sure whether this makes sense... Probably it might be better > not to include the tag, as it wouldn't make sense anymore > (what's the title of a non-existant resource), but I'm just shooting out > ideas. By similar reasoning, link doesn't make sense. Depending on the source, not all CMS may know when a delete took place or even *IF* a deletion took place. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 18 08:02:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29844 for <atompub-archive@lists.ietf.org>; Wed, 18 Aug 2004 08:02:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IBqwNp021377; Wed, 18 Aug 2004 04:52:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IBqwQP021376; Wed, 18 Aug 2004 04:52:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IBqvxW021365 for <atom-syntax@imc.org>; Wed, 18 Aug 2004 04:52:57 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7IBskQX003142; Wed, 18 Aug 2004 07:54:46 -0400 Message-ID: <41234319.7060902@intertwingly.net> Date: Wed, 18 Aug 2004 07:52:57 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Brickley <danbri@w3.org> CC: atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> <p06110462bd485896d86e@[10.20.30.249]> <6.1.2.0.2.20040817205856.0262f8b8@www.gosmalltalk.com> <p06110470bd48710891ee@[10.20.30.249]> <20040818074720.GA24078@homer.w3.org> In-Reply-To: <20040818074720.GA24078@homer.w3.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dan Brickley wrote: > > Extensibility comes at a price, and designing something cleaner and > better than RDF will be an interesting endeavour. Finding a clean and > syntactically graceful way of mapping _into_ RDF also comes at a price, > as does (of course) simply using full RDF/XML syntax. The pre-IETF > Atom community decided some time ago that they didn't find RDF/XML > an attractive proposition, which I guess means we're going the route of > defining an extensibility model that is somehow better than RSS 1.0's. If you were to express that paragraph as a set of assertions, you would find something missing. I'm going to extract a few, please forgive my inprecise way of expressing them: RSS 1.0 uses RDF. RDF addresses some extensibility problems. RDF/XML is a serialization syntax for RDF. pre-IETF community didn't find the RDF/XML syntax attractive. What can we conclude from this? First, for purposes of this discussion, lets not debate the assertion that RDF addresses extensibility issues, and simply treat it as a given. And let's assume, again for purposes of discussion, that the AtomPub working group is interested in pursing a non-RDF/XML serialization syntax. Even with all these assumptions, can we conclude that "we're going the route of defining an extensibility model that is somehow better than RSS 1.0's."? I don't think so. Hint: there are other serialization syntaxes than RDF/XML. Further reading: http://www.xml.com/pub/a/2003/08/20/dive.html http://semtext.org/atom/utils.html http://www.w3.org/2004/01/rdxh/spec - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 18 08:24:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01233 for <atompub-archive@lists.ietf.org>; Wed, 18 Aug 2004 08:24:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ICBM2P029383; Wed, 18 Aug 2004 05:11:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ICBMRd029381; Wed, 18 Aug 2004 05:11:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ICBMRB029367; Wed, 18 Aug 2004 05:11:22 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 63F254F00B; Wed, 18 Aug 2004 08:11:23 -0400 (EDT) Date: Wed, 18 Aug 2004 08:11:23 -0400 From: Dan Brickley <danbri@w3.org> To: Dare Obasanjo <kpako@yahoo.com> Cc: Paul Hoffman / IMC <phoffman@imc.org>, James Robertson <jarober@gosmalltalk.com>, atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats Message-ID: <20040818121123.GD2706@homer.w3.org> References: <20040818074720.GA24078@homer.w3.org> <20040818082445.62583.qmail@web41202.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040818082445.62583.qmail@web41202.mail.yahoo.com> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> * Dare Obasanjo <kpako@yahoo.com> [2004-08-18 01:24-0700] > > - (fairly) predictable XML notation; RSS 1.0 > > defined a profile of the > > RDF/XML syntax, so that namespace-extended feeds > > all shared a > > basic structure. (rather than allowing all RDF's > > syntactic > > variations). > > How is this practically useful? The fact that an > extension will show up as single elements with simple > content or as elements with attributes and complex > contents doesn't bring my application any closer to > understanding them when encountered in the wild. We're not talking AI here. Just data mixing and a decentralised division of labour. RDF's contribution is really a strategy for decentralising vocabulary design. When someone designs an RDF vocabulary, the things they name and describe in their namespaces are classes (categories) and properties (relationships etc.). When someone designs an XML vocabulary, the things they name and describe in their namespace are XML elements and attributes. In the RDF case, the vocabulary is described in terms of the world; you say things like "'wrote' is a relationship between an 'Agent' and a 'Work'", or "'JPEGImage' is a sub-class of 'Image'"; in the XML case, you talk more explicitly about markup patterns, rather than about the things that markup tells you about the world. So we end up with committees and groups inventing XML markup, and their primary means of expression is the ability to say, basically, which XML elements can live inside which other XML elements, in what order, and which attributes they are allowed to be decorated with. And there are half a dozen schema languages these guys can use to do that job in slightly different ways. All RDF namespaces, by contrast, are based on the RDF Schema approach (perhaps using the OWL extensions). My problem with the "let them eat namespaces" view is that it ignores the social mechanics that gets us this mixed-namespace markup in the first place. I'm perfectly willing to believe that one could write XQuery or XSLT or DOM+.js to consume mixed markup, *assuming* that some collection of parties had figured out conventions for mixing their namespaces together. But that more takes time, effort and money to achieve at a fine grained level if you opt-out of the RDF infrastructure. Non-XML namespaces can sit alongside each other in an XML tree, or live one inside the other, but generally we've seen precious little by way of freely mixable XML namespaces. By contrast, *all* RDF vocabularies can be deployed in a mixed way, out of the box, because RDF indirects through a common data model and XML encoding which imposes some common conventions across otherwise indpendent vocabularies. The idea that different parties "simply create their own XML namespaces" is problematic because the world doesn't come organised into nicely parceled, crisply discrete problem spaces, each with their own MyProblemSpaceML markup notation. Things are horribly jumbled up (which is why AI failed to deliver, imho). So you think you're working on a "digital images" markup language for photos, and you find you're spending half your time thinking about geographic markup, or representing the content of the picture, or fending of motionpicture people who claim your problem space is subsumed by theirs. You think you're working on geographic markup, places and coordinates and maps, and find yourself drawn into modelling the things that are on the map. You think you're creating bibliographic metadata but find it to be intimately tangled up with rights metadata, with educational level classification metadata (which btw crops up again if you're doing jobs, CVs, and personal profile work (and which varies wildly between countries)). Everything is jumbled up with everything else, and so we need some conventions for people to get out there and do their bit without waiting for everyone else to finish the other bits of the puzzle. Should the folk doing Job advert markup have a meeting with the people doing geo markup or postal addresses, to decide whose tags can go in whose, and update their schemas accordingly? What about CVs? Photos? Bibliographies, educational metadata, rights, and so and so on? I got on board the RDF train after being burnt out from attending so-called metadata initiative meetings (primarily biblio, imaging, education, search) where people were merrily creating tagsets whose scope and features overlapped and who badly needed a bit more architecture for fine grained mixing, so they could concentrate better on their area of expertise, and leave the detail of other areas to be fleshed out by folk with complimentary exercise. Without having to sit around a table with them arguing about XML tag nesting structures. This is not, and shouldn't be mistaken for, the old AI dream of machine intelligence. It's simply a wish to have to fly around to fewer standards coordination meetings. And to do that, we need some high level things that all XML namespaces have in common. Whether tag order is significant, for example (in RDF, it almost always isn't). Whether there's negation-as-failure closed world assumptions (in RDF, we avoid this), a convention for knowing whether an element stands for a category of thing, or a kind of relationship between things, etc etc. There are several options. We can hope that people somehow create XML namespaces that play well together, in the absence of such conventions. This hasn't happened yet, but there's always hope. Or we can try to invent some such conventions within the AtomPub WG (add 11-24 months to the schedule; plus same again 2 years later to fix mistakes), or we can back off from the 'Atom everywhere' rhetoric and decide that Atom's really about interop in the blogging world, and that full on data syndication is a v2.0 problem, and that v1.0 targets bloggers. When feeds are carrying rich namespace-extended descriptions of the things the feeds describe (jobs, journals, products, holidays, pornography, people, cities, mail messages, CVS servers, journal articles, paper-published books, MP3s, Ogg streams, playlists, concert listings, weather reports, security alerts, blog comments, answerphone messages, bank transactions, network outages, TV schedules, dentist appointments, football results, product recalls, train times, blind dates, press releases and -yesyes- blog posts, ... *then* we'll have 'atom everywhere'. But unless we're going to slip back 5 years in terms of expressivity, Atom needs a way to allow all these kinds of thing to be described using whatever externally-managed namespaces make sense in the marketplace. For externally managed namespaces to make sense when deployed together, they need to be designed with that in mind. Which brings us back to the frameworks on offer to folk creating those namespaces. The examples I gave above are mix. There's some blogging and information-resource use cases in there (though digital library stuff quickly shades off into complexity). There's a lot of things focussed around people, around places, and in particular around events. Hardly suprising; syndication is event-centric. Not blog posting events, but events in the world that are associated in various (potentially nameable) ways with the information items we syndicate in XML. The AtomPub WG isn't (AFAIK) in the business of providing exhaustive descriptions of events, of places, of people. It is, perhaps, in the business of providing a syndication framework where richer descriptions of these things (and more) can be mixed together. This doesn't mean that all Atom code needs to understand them, or will magically become intelligent and able to act upon new markup. Just that there could usefully be a few common patterns for mixed-namespace markup which allow the ***huge*** task of describing all this stuff to be divided up amongst parties who may never meet or even be working on their namespaces at the same time. (I like the OpenGALEN slogan here; "making the impossible very difficult" ;) So we should always be thinking about how to divide up the work, ie. what can we say to people who want to contribute a better way to describe jobs, drawing upon existing work re skills description, topics, location? What to say to people who want to syndicate photo metadata, drawing upon lat/long markup, 'who is in this photo' markup, common nouns, EXIF fields, and so on. Do we encourage them to have anything in common with each other's efforts, or just say "use XML+namespaces, go invent some named elements and attributes and tell us what markup patterns you consider valid". If they go the vanilla XML+namespaces route, they get to pick some named XML elements and attributes, and say some stuff about which element combination patterns are allowed, and how they can be decorated with XML attributes. If they go the RDF route, they don't get asked which elements theirs can go inside, and which can go inside there, **because it isn't up to them**. RDF quite explicitly witholds that ability from the creators of a namespace, so that we don't force people to anticipate all future uses of their creation, or get into rigid and fragile versioning coalitions with owners related tagsets. (and no, RDF doesn't solve the namespace versioning problem, but it makes it approachable, or at least merely very hard). The RDF approach isn't trying to make data universally understandable in any fancy AI sense, just universally mixable. If I want to aggregate jobs data, I need to know a bit about Jobs-related namespaces. If I want a really smart Jobs aggregator, I'll go and investigate namespaces that relate to places, to events/time, to skill and topic description, and to geography. And I'd be well-advised to create some nice tools that actually use that data, and go evangelise those extensions to parties who'll create enough feeds to get some adoption. No magic, just a bit of structure around a lot of hard work. > I see this in RSS 2.0 as well. RSS 2.0 says "how these namespaces get designed and how they play together isn't our problem". Which brings us back to the scoping question. If AtomPub's deliverable is really focussed around weblogging, then maybe it's OK to say "we don't know yet; maybe in Version 2". But if Atom is to be marketed as the backbone for Web-based data syndication, establishing a framework that'll serve us for decades to come, then the "not our problem" approach to mixed-namespace design simply doesn't cut it. cheers, Dan From owner-atom-syntax@mail.imc.org Wed Aug 18 08:37:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01849 for <atompub-archive@lists.ietf.org>; Wed, 18 Aug 2004 08:37:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ICKobT033705; Wed, 18 Aug 2004 05:20:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ICKoMQ033704; Wed, 18 Aug 2004 05:20:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ICKo7d033696 for <atom-syntax@imc.org>; Wed, 18 Aug 2004 05:20:50 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id BFEB04EF96; Wed, 18 Aug 2004 08:20:51 -0400 (EDT) Date: Wed, 18 Aug 2004 08:20:51 -0400 From: Dan Brickley <danbri@w3.org> To: Sam Ruby <rubys@intertwingly.net> Cc: atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats Message-ID: <20040818122051.GE2706@homer.w3.org> References: <6324F8E0-EF09-11D8-9BC6-000A95BD86C0@mnot.net> <5B372FCC-F0A7-11D8-99EE-000A95A51C9E@sun.com> <6.1.2.0.2.20040817195414.026ea028@www.gosmalltalk.com> <p06110462bd485896d86e@[10.20.30.249]> <6.1.2.0.2.20040817205856.0262f8b8@www.gosmalltalk.com> <p06110470bd48710891ee@[10.20.30.249]> <20040818074720.GA24078@homer.w3.org> <41234319.7060902@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41234319.7060902@intertwingly.net> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> * Sam Ruby <rubys@intertwingly.net> [2004-08-18 07:52-0400] > Dan Brickley wrote: > > > >Extensibility comes at a price, and designing something cleaner and > >better than RDF will be an interesting endeavour. Finding a clean and > >syntactically graceful way of mapping _into_ RDF also comes at a price, > >as does (of course) simply using full RDF/XML syntax. The pre-IETF > >Atom community decided some time ago that they didn't find RDF/XML > >an attractive proposition, which I guess means we're going the route of > >defining an extensibility model that is somehow better than RSS 1.0's. > > If you were to express that paragraph as a set of assertions, you would > find something missing. I'm going to extract a few, please forgive my > inprecise way of expressing them: > > RSS 1.0 uses RDF. > RDF addresses some extensibility problems. > RDF/XML is a serialization syntax for RDF. > pre-IETF community didn't find the RDF/XML syntax attractive. > > What can we conclude from this? (That the baby is at risk because of the bathwater? ;) > First, for purposes of this discussion, lets not debate the assertion > that RDF addresses extensibility issues, and simply treat it as a given. > And let's assume, again for purposes of discussion, that the AtomPub > working group is interested in pursing a non-RDF/XML serialization syntax. > > Even with all these assumptions, can we conclude that "we're going the > route of defining an extensibility model that is somehow better than RSS > 1.0's."? > > I don't think so. > > Hint: there are other serialization syntaxes than RDF/XML. > > Further reading: > http://www.xml.com/pub/a/2003/08/20/dive.html > http://semtext.org/atom/utils.html > http://www.w3.org/2004/01/rdxh/spec Yes. I skirted this a little, but that's an important message: it would be unfortunate to confuse RDF with it's current/primary XML serialization (aka "RDF/XML"). BTW things are moving along with GRDDL, it is now published as a W3C Note, http://www.w3.org/TR/2004/NOTE-grddl-20040413/ (GRDDL, briefly, provides some conventions for pointing to an XSLT that turns some markup into RDF/XML). The XHTML folk have also just shipped a Working Draft that shows a revision to the <link/> and <meta/> constructs in a way that allows it to be treated as an alternate XML notation for RDF graphs. See http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-metaAttributes.html#s_metaAttributesmodule http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-meta.html#s_metamodule Needless-ish to say, ongoing work on RDF querying (http://www.w3.org/2001/sw/DataAccess/) is agnostic about RDF concrete syntaxes, since it is couched in terms of the graph data model. The same goes for all the vocabulary namespaces listed at http://www.schemaweb.info/ cheers, Dan From owner-atom-syntax@mail.imc.org Wed Aug 18 09:43:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05310 for <atompub-archive@lists.ietf.org>; Wed, 18 Aug 2004 09:43:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IDUeRN058815; Wed, 18 Aug 2004 06:30:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IDUelO058814; Wed, 18 Aug 2004 06:30:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pulse.betaversion.org ([62.140.213.123]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IDUb0i058803 for <atom-syntax@imc.org>; Wed, 18 Aug 2004 06:30:39 -0700 (PDT) (envelope-from pier@betaversion.org) Received: (qmail 22137 invoked from network); 18 Aug 2004 13:30:36 -0000 Received: from unknown (HELO ?10.11.155.45?) (pier@62.140.213.2) by pulse.betaversion.org with SMTP; 18 Aug 2004 13:30:36 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <412339B0.4020900@intertwingly.net> References: <C504423B-F06F-11D8-9256-000A95984AEA@betaversion.org> <412339B0.4020900@intertwingly.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-711998798; protocol="application/pkcs7-signature" Message-Id: <C7331ECE-F11A-11D8-B891-000A95984AEA@betaversion.org> From: Pier Fumagalli <pier@betaversion.org> Subject: Re: Syndication of updates and deletions of content Date: Wed, 18 Aug 2004 14:30:31 +0100 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --Apple-Mail-5-711998798 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 18 Aug 2004, at 12:12, Sam Ruby wrote: > Pier Fumagalli wrote: >> Now, how would I syndicate the fact that a resource is gone away? Of >> course I won't include in the syndication feed all of our content >> (more than 100k articles), but only what happened in the (let's say) >> past 24 hours. But how can a subscriber to my Atom feed know whether >> a resource is simply not included, or it was actually removed? > > What do you think that subscribers MAY do with this information? > SHOULD? MUST? > > Are there ever cases where a publisher MUST or SHOULD include deleted > information in a feed? Imagine a search engine allowing me to search on a bunch of aggregated blogs. If I go to (for example) JavaBlogs and search for "Sam Ruby", the first entry I'm going to match is Bill de Hora's post of August 15th 2003. If you click on that link, and try to access Bill's blog, you'll go to a _completely different_ blog post (don't ask me why), if you click on "read" on the other hand, you'll see the original content of the blog... Now, something tells me that Bill deleted the "Sam Ruby: Inter-net" post, and replaced it, and in no way the search engine was able to pick this, and it is serving (now) the wrong content. Subscribers MAY use this information to know that a specific post has expired, and SHOULD delete all local references if they cache the original content. If the feed doesn't allow for a deletion/removal/expiration mechanism, the only way in which I can make sure of that, is crawl all the blog posts I'm indexing, one by one, and verify if they're still there. And consider that my employer wants to start syndicating roughly 115.000 articles using atom... That's quite a challenge! :-P >> I thought about having an "entry" structured in this way: >> <entry> >> <title>Microsoft lists apps affected by XP SP2 >> http://www.vnunet.com/news/1157398 >> > href="http://www.vnunet.com/news/1157398"/> >> 2004-08-17T08:29:29Z >> >> but I'm not sure whether this makes sense... Probably it might be >> better not to include the tag, as it wouldn't make sense >> anymore (what's the title of a non-existant resource), but I'm just >> shooting out ideas. > > By similar reasoning, link doesn't make sense. Depending on the > source, not all CMS may know when a delete took place or even *IF* a > deletion took place. Good point... Maybe just <id> and <deleted> are actually pertinent to the notification of a removal event. Pier --Apple-Mail-5-711998798 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwttIjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTA3MDE0MjIwWhcNMDUwMTA2MDE0MjIwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRwaWVyQGJldGF2ZXJzaW9u Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMC/E+M4UqeEBnSTj0AIMX9oMWSo 9Te7VUPPvINPSKKLEElGaottQeJaYRSlfGIjUyXkzTlbw0MFAPaqfU97t+5xeNkighKu7ZcVIPfz AARv5+wp+gON5uSNV2GzP0rPwAbUDIG2zaSonJlN7whVG5fO9G1u0oYaWolpgKUAc3T5P5Gv737L G1iSxrnl9DQlVDIuZWrcgWYX/MFFlf7prXXm6lS08lYhGi0NrIf5SploZzMG+uHHzVDgV8WCTQr1 hXB825VLhnWw4GPFx5qLVgElctVz88S/+t8O/+1kRf3ky8SsewfyCTuDAk4XHzfb7M5bECiZ1yni dhW+sD1y/TsCAwEAAaMxMC8wHwYDVR0RBBgwFoEUcGllckBiZXRhdmVyc2lvbi5vcmcwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAjeSEnk3U1P46rHiBGJP7StkQg/DVkw4ModEYCEwxm 8QYxQPGMciXn2goZ5ahK6Uu8Rfa+ZPSxV96VFsOlc3oFF02VYsrRy+xJukuSMY0z/0UvHnTZmVfm CJpxMoVMYQO3fC2XdmCNASu8FbvOgaS71fQf3b0wgebLeLROR7u5XjCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC20iMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxODEzMzAzMlowIwYJKoZIhvcNAQkEMRYEFLIE ldNhxOpzdQiKCIMdsbBt5g3oMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLbSIwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC20iMA0GCSqGSIb3DQEBAQUABIIBAFB/ olEMgdCRq9APwg+jWntwnh9jZBitEIBktuc46/E0I18uAzQgq2nhikp5+6W2UPwr9cHfrpvpyU4q oJDMC+4PTTTppCgdRop5GAyiIols/IFRKuEHmAkZfSzMYfSew7uReFzh47n6S9lG2xhcKLa9t23v lDk/QdlbYnVh4qejU1l089oB94kSnT3868zYHWDariUYe1BYqcLCtZ6F3nohLSA3zJdrY/xReJID VMksnrcF9wysQdXEQLWaKm87yrqGM64ab3o7dpiC+KTNP2EFpnHR01u/8M0DApDnGxYjerDwR8v8 rVWTUjMPn+q8yoeswGYItSTwRO58o4L2pXwAAAAAAAA= --Apple-Mail-5-711998798-- From owner-atom-syntax@mail.imc.org Wed Aug 18 09:49:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05721 for <atompub-archive@lists.ietf.org>; Wed, 18 Aug 2004 09:49:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IDfvvw061168; Wed, 18 Aug 2004 06:41:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IDfvUe061167; Wed, 18 Aug 2004 06:41:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m018e36d0.tmodns.net [208.54.142.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IDfvMN061155 for <atom-syntax@imc.org>; Wed, 18 Aug 2004 06:41:57 -0700 (PDT) (envelope-from jarober@gosmalltalk.com) Received: from james2.gosmalltalk.com (unknown [10.243.46.100]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 38E18189C6 for <atom-syntax@imc.org>; Wed, 18 Aug 2004 06:25:40 -0700 (PDT) Message-Id: <6.1.2.0.2.20040818094055.025b2a70@www.gosmalltalk.com> X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 18 Aug 2004 09:41:33 -0400 To: atom-syntax@imc.org From: James Robertson <jarober@gosmalltalk.com> Subject: Re: Extensibility in Syndication formats In-Reply-To: <1f2ed5cd04081802471becfcd7@mail.gmail.com> References: <20040818082445.62583.qmail@web41202.mail.yahoo.com> <1f2ed5cd04081802471becfcd7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At least in my case, the cost to support that kind of extension is identical - so RDF buys me nothing. >I'm a little surprised to find that you still hold this opinion, but >ok, by way of example. Say you wanted your RSS entry to describe a >project. In RSS 2.0 you might have something like: > ><item> ><guid>http://example.org</guid> ><title>My Project > > My Project > http://example.org/home > > > >In RSS 1.0 it might look like: > > >My Project >... > > > > My Project > > > >If the consumer understands the project vocabulary, then full >communication can take place with either version. However, assume the >consumer knows nothing about the project extension. > >If the consumer understands RDF/XML syntax, then from the RSS 1.0 >version it can determine that: > >1. the item resource is an instance of the class doap:Project >2. the item has a literal property, doap:name with the value "My Project" >3. the item has a property with a resource as it's value, the URI >being "http://example.org/home" >4. that doap:Project is an rdfs:Class >5. that doap:name is an rdf:Property with a domain including doap:Project >6. that doap:homepage is an rdf:Property with a domain including doap:Project >7. that doap:homepage is an rdf:Property >(and a few other bits) > >If the consumer is aware of the RDF Schema for doap, then it also has >access to other information, for example that doap:name is an >rdfs:subPropertyOf rdf-schema#label". This could be used to decide how >to render the value for display. > >If the consumer understands RSS 2.0, XML and namespaces, then it still >understands absolutely *nothing* about the project information, not >even that it applies to the same item. > >Partial understanding is only one advantage, another big one is that >RSS/RDF vocabularies can be mixed and matched with impunity and still >carry that partial understanding (if fact, combined partial >understanding of all the parts). On the other hand, mixtures of >arbitrary combinations of RSS 2.0-based extensions are undefined, and >there is nothing to prevent conflicts in their interpretation >(namespaces separate the terms, but conflicts may appear at a higher >level in the app). > >See also: > >http://www.xml.com/pub/a/2003/07/23/extendingrss.html > >Cheers, >Danny. James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView jarober@gosmalltalk.com From owner-atom-syntax@mail.imc.org Wed Aug 18 11:19:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12769 for ; Wed, 18 Aug 2004 11:19:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IF3rSs074503; Wed, 18 Aug 2004 08:03:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IF3rJn074502; Wed, 18 Aug 2004 08:03:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IF3qMU074485 for ; Wed, 18 Aug 2004 08:03:52 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc13) with SMTP id <2004081815034901500sdifoe>; Wed, 18 Aug 2004 15:03:50 +0000 Date: Wed, 18 Aug 2004 09:03:48 -0600 Subject: Re: Extensibility in Syndication formats Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <1f2ed5cd04081802471becfcd7@mail.gmail.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, August 18, 2004, at 03:47 AM, Danny Ayers wrote: > In RSS 2.0 you might have something like: > > > http://example.org > My Project > > My Project > http://example.org/home > > > > In RSS 1.0 it might look like: > > > My Project > ... > > > > My Project > > > > If the consumer understands the project vocabulary, then full > communication can take place with either version. However, assume the > consumer knows nothing about the project extension. > > If the consumer understands RDF/XML syntax, then from the RSS 1.0 > version it can determine that: > > 1. the item resource is an instance of the class doap:Project ... > If the consumer understands RSS 2.0, XML and namespaces, then it still > understands absolutely *nothing* about the project information, not > even that it applies to the same item. After thinking about this briefly and realizing what it meant (I think), this became the single most interesting point yet to come out of this discussion. Allow me to make another example (with some fanciful elements and structure) to illustrate the point and see if I understand it correctly: My title Joe http://www.joe.com/ blue white From this, we know that the item has an author and colors, but what do the elements inside ... and ... describe? The author, or the item? The "colors", whatever that is, or the item? We must understand this XML syntax to know. My title Joe blue white Not being very familiar with RDF/XML, I have a nagging suspicion that I've done something wrong having the author right inside the item, but the point is that now we know that the author's is referring to the author, and not the item, and that the and colors are referring to the item (or, more precisely, to the same thing that the item is referring to), because the rdf:about URI for and is the same--they're talking about the same thing. Does that capture a non-trivial part of what RDF gets us? That we can tell exactly what each piece of data is talking about? And as more extensions are added to make places for more types of data within an Atom feed, however they may or may not be nested, we don't end up confused about what thing any particular piece of data is describing? From owner-atom-syntax@mail.imc.org Wed Aug 18 11:33:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14230 for ; Wed, 18 Aug 2004 11:33:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IFKdik077136; Wed, 18 Aug 2004 08:20:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IFKdf2077135; Wed, 18 Aug 2004 08:20:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IFKcqx077124 for ; Wed, 18 Aug 2004 08:20:38 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7IFKcT8028890 for ; Wed, 18 Aug 2004 11:20:39 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BNO36613 (AUTH bob@wyman.us); Wed, 18 Aug 2004 11:20:36 -0400 (EDT) Message-Id: <200408181520.BNO36613@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom-Syntax'" Subject: It's about Reading -- not Writing... Date: Wed, 18 Aug 2004 11:20:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSFNumziaju7A5DQvK4QG0wRcIRmA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit If a message is written but never read, was anything communicated? If a tree falls in a forest... Atom and syndication are about communication - the authors of entries have rhetorical intent. Thus, the standard and formal rules of rhetoric apply. Speakers, or writers, are responsible for understanding the warrants (i.e. prior knowledge, etc) of their audience -- and they are responsible for speaking or writing in a language that their audience can understand. Speakers are *constrained* by their audiences to limit their speech to that which can be understood. If the speaker doesn't accept the constraints, then communication doesn't occur. If there is a failure to communicate, it is the responsibility of the speaker -- not the audience. RDF may contribute, as Dan Brickley says, "a strategy for decentralizing vocabulary design." However, the goal of the Atom effort is to contribute a "strategy and means for communicating information." The problems of designing vocabulary and of employing vocabulary (communicating) are distinct. The RDF camp seems enthralled by the glory of being able to easily *express* a vast range of ideas with what is, at its core, a very simple set of rules. However, we've learned over and over that RDF is more often written then read. Non-RDF XML is the language of readers -- not RDF. The reason is simple... RDF gives so much freedom to the writer that that reader has little hope of understanding what is written. What one can understand about something written in RDF is often no more meaningful then the examples that Danny Ayers provides elsewhere. (e.g. Some unknown thing is said to have a property which has unknown, but named, properties and that something is said to have some undefined relationship to some other unknown thing... How is this useful?) If one is communicating in a small group it is reasonable to utilize private vocabularies -- to produce "jargon" as it were. Small groups do this constantly -- with our without RDF. But, if you wish to communicate to a large group then, in order to *communicate*, you must express yourself with a broadly understood and more rigorous language. The opportunity for variety and creativity in message construction is reduced as the size the audience increases. The key challenge of Atom is, I believe, to enable speaking to large audiences. Thus, Atom should focus first on the problem of providing a well and rigorously defined vocabulary that can be shared efficiently by a large audience. Atom should be optimized for communications. I believe that this means that Atom should rely on rigorously defined XML -- complete with schemas, etc. RDF is certainly a useful tool for "vocabulary design" and can be very effective in small, closely-coupled groups -- thus, RDF can be useful to those who are experimenting with and designing early vocabularies that might later be formalized for broad use. In some small groups, the focus of communications is so limited that such formalization may not ever be justified or even necessary. Given this, I think Atom should provide a means to encapsulate RDF within its XML -- to enable experimentation and communication within fringe groups. However, once a vocabulary has been "designed" as a result of small group RDF use, it simply doesn't make sense to continue using RDF. Once the vocabulary, or its core, has become fixed and well understood, the flexibility of RDF becomes both a burden (because of bulk, parsing difficulties, etc.) as well as unnecessary to communicate those things that have been formalized. Thus, *formal* extensions to Atom, intended to be used by the broad market, should be defined rigorously in as non-RDF XML. Insisting on XML as the format for broad audience communication does nothing to limit the RDF people. As shown by GRDDL[1], you can convert easily between XML and RDF. The RDF-folk can view the whole world as RDF if they want... On the other hand, insisting on well and rigorously defined XML for Atom will make it much more likely that the users of Atom will be able to accomplish their communications goals -- because they will have agreed upon common vocabularies with some sense that their audience, *the readers* of Atom files, will understand. The Atom extensibility mechanisms should address at least two concerns: 1. Adding additional "standard" elements that are expected to be understood by *all* or a large number of Atom readers. 2. Providing the flexibility needed by vocabulary designers, small groups, and others who require or desire non-standard vocabularies. The mechanisms which are most appropriate to handle the first concern are probably not the same as those which are most appropriate for the second. Please remember: It's about reading -- not writing... bob wyman From owner-atom-syntax@mail.imc.org Wed Aug 18 11:52:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15939 for ; Wed, 18 Aug 2004 11:52:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IFZgdZ079412; Wed, 18 Aug 2004 08:35:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IFZg4O079411; Wed, 18 Aug 2004 08:35:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IFZg3L079390 for ; Wed, 18 Aug 2004 08:35:42 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040818153540.33046.qmail@web41203.mail.yahoo.com> Received: from [24.18.136.49] by web41203.mail.yahoo.com via HTTP; Wed, 18 Aug 2004 08:35:40 PDT Date: Wed, 18 Aug 2004 08:35:40 -0700 (PDT) From: Dare Obasanjo Subject: Re: Extensibility in Syndication formats To: Dan Brickley Cc: Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org In-Reply-To: <20040818121123.GD2706@homer.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Dan Brickley wrote: > > > > How is this practically useful? The fact that an > > extension will show up as single elements with > simple > > content or as elements with attributes and complex > > contents doesn't bring my application any closer > to > > understanding them when encountered in the wild. > > We're not talking AI here. Just data mixing and a > decentralised > division of labour. Before continuing, I'd like to note that besides [perhaps] NewsMonster of the dozens of RSS aggregators I have seen in action none treat extensibility in RSS 1.0 any different from extensibility in RSS 2.0. It's all just XML and namespaces to them. The other aggregator authors on the list can pipe up and disagree with me if I am mistaken. Thus the claims of superiority of using RDF-based extensibility in RSS 1.0 versus using XML + namespaces as RSS 2.0 does have simply never been shown in the wild besides the proof of concept stuff that the RDF syndication usual suspects like Danny Ayers trot out whenevr this discussion occurs. > RDF's contribution is really a strategy for > decentralising vocabulary > design. When someone designs an RDF vocabulary, the > things they name > and describe in their namespaces are classes > (categories) and > properties (relationships etc.). When someone > designs an XML vocabulary, > the things they name and describe in their namespace > are XML elements and > attributes. In the RDF case, the vocabulary is > described in terms of the > world; you say things like "'wrote' is a > relationship between an 'Agent' > and a 'Work'", or "'JPEGImage' is a sub-class of > 'Image'"; in the XML > case, you talk more explicitly about markup > patterns, rather than about > the things that markup tells you about the world. So > we end up with > committees and groups inventing XML markup, and > their primary means > of expression is the ability to say, basically, > which XML elements can > live inside which other XML elements, in what order, > and which attributes > they are allowed to be decorated with. And there are > half a dozen schema > languages these guys can use to do that job in > slightly different ways. > All RDF namespaces, by contrast, are based on the > RDF Schema approach > (perhaps using the OWL extensions). So far I haven't seen something which indicates a better extensibility model when using RDF versus XML + namespaces. It is more likely that an XML language contains constructs that don't map to real world constructs but instead are just there for markup purposes but I see the same in RDF/XML as well with all the sequences, lists and bags which don't even occur in RSS 2.0 anyway. In fact one could argue that there is more of a 1:1 mapping between syndication construct in the typical RSS 2.0 document than in an RSS 1.0 document describing the same data. > My problem with the "let them eat namespaces" view > is that it ignores > the social mechanics that gets us this > mixed-namespace markup in the > first place. I'm perfectly willing to believe that > one could write > XQuery or XSLT or DOM+.js to consume mixed markup, > *assuming* that some > collection of parties had figured out conventions > for mixing their > namespaces together. But that more takes time, > effort and money to > achieve at a fine grained level if you opt-out of > the RDF infrastructure. > Non-XML namespaces can sit alongside each other in > an XML tree, or live > one inside the other, but generally we've seen > precious little by way of > freely mixable XML namespaces. By contrast, *all* > RDF vocabularies can > be deployed in a mixed way, out of the box, because > RDF indirects > through a common data model and XML encoding which > imposes some common > conventions across otherwise indpendent > vocabularies. So far all you've done is assert that RDF based extensibility is better without showing why in concrete terms. I don't see why you claim it is so hard to reuse an element from one schema in another, it hapopens all the time in the world of RSS. Heck, just a few days ago on this list we were discussing using the dcterms:* elements in Atom without resorting to using RDF-based extensibility, just XML and namespaces. > The idea that different parties "simply create their > own XML namespaces" > is problematic because the world doesn't come > organised into nicely > parceled, crisply discrete problem spaces, each with > their own > MyProblemSpaceML markup notation. Things are > horribly jumbled up > (which is why AI failed to deliver, imho). > > So you think you're working on a "digital images" > markup language > for photos, and you find you're spending half your > time thinking > about geographic markup, or representing the content > of the picture, > or fending of motionpicture people who claim your > problem space > is subsumed by theirs. You think you're working on > geographic > markup, places and coordinates and maps, > and find yourself drawn into modelling the things > that are on the map. > You think you're creating bibliographic metadata but > find it to be > intimately tangled up with rights metadata, with > educational level > classification metadata (which btw crops up again if > you're doing jobs, > CVs, and personal profile work (and which varies > wildly between > countries)). Everything is jumbled up with > everything else, and so we > need some conventions for people to get out there > and do their bit > without waiting for everyone else to finish the > other bits of the > puzzle. > > Should the folk doing Job advert markup have a > meeting with the people > doing geo markup or postal addresses, to decide > whose tags can go in > whose, and update their schemas accordingly? What > about CVs? Photos? > Bibliographies, educational metadata, rights, and so > and so on? I got on > board the RDF train after being burnt out from > attending so-called > metadata initiative meetings (primarily biblio, > imaging, education, > search) where people were merrily creating tagsets > whose scope and > features overlapped and who badly needed a bit more > architecture for > fine grained mixing, so they could concentrate > better on their area of > expertise, and leave the detail of other areas to be > fleshed out by > folk with complimentary exercise. Without having to > sit around a table > with them arguing about XML tag nesting structures. > > This is not, and shouldn't be mistaken for, the old > AI dream of > machine intelligence. It's simply a wish to have to > fly around to fewer > standards coordination meetings. And to do that, we > need some high level > things that all XML namespaces have in common. > Whether tag order is > significant, for example (in RDF, it almost always > isn't). Whether > there's negation-as-failure closed world assumptions > (in RDF, we avoid > this), a convention for knowing whether an element > stands for a category > of thing, or a kind of relationship between things, > etc etc. > > There are several options. We can hope that people > somehow create XML > namespaces that play well together, in the absence > of such conventions. > This hasn't happened yet, but there's always hope. > Or we can try to > invent some such conventions within the AtomPub WG > (add > 11-24 months to the schedule; plus same again 2 > years later to fix > mistakes), or we can back off from the 'Atom > everywhere' rhetoric and > decide that Atom's really about interop in the > blogging world, and > that full on data syndication is a v2.0 problem, and > that v1.0 targets > bloggers. > > When feeds are carrying rich namespace-extended > descriptions of the things > the feeds describe (jobs, journals, products, > holidays, pornography, people, > cities, mail messages, CVS servers, journal > articles, paper-published > books, MP3s, Ogg streams, playlists, concert > listings, weather reports, security > alerts, blog comments, answerphone messages, bank > transactions, network > outages, TV schedules, dentist appointments, > football results, product > recalls, train times, blind dates, press releases > and -yesyes- blog posts, > ... *then* we'll have 'atom everywhere'. But unless > we're going to slip > back 5 years in terms of expressivity, Atom needs a > way to allow all > these kinds of thing to be described using whatever > externally-managed > namespaces make sense in the marketplace. RSS 2.0 does all these and more today. It seems you are either ignorant of what's happening in the syndication space today or willfully ignoring the current state of the syndication marketplace. > For externally managed namespaces to make sense when > deployed together, > they need to be designed with that in mind. Which > brings us back to > the frameworks on offer to folk creating those > namespaces. The examples > I gave above are mix. There's some blogging and > information-resource use > cases in there (though digital library stuff quickly > shades off into > complexity). There's a lot of things focussed around > people, around > places, and in particular around events. Hardly > suprising; syndication > is event-centric. Not blog posting events, but > events in the world that > are associated in various (potentially nameable) > ways with the information > items we syndicate in XML. The AtomPub WG isn't > (AFAIK) in the > business of providing exhaustive descriptions of > events, of places, > of people. It is, perhaps, in the business of > providing a syndication > framework where richer descriptions of these things > (and more) can be > mixed together. This doesn't mean that all Atom code > needs to understand > them, or will magically become intelligent and able > to act upon new markup. > Just that there could usefully be a few common > patterns for mixed-namespace > markup which allow the ***huge*** task of describing > all this stuff to > be divided up amongst parties who may never meet or > even be working on their > namespaces at the same time. (I like the OpenGALEN > slogan here; "making the > impossible very difficult" ;) > > So we should always be thinking about how to divide > up the work, ie. > what can we say to people who want to contribute a > better way to > describe jobs, drawing upon existing work re skills > description, topics, > location? What to say to people who want to > syndicate photo metadata, > drawing upon lat/long markup, 'who is in this photo' > markup, common > nouns, EXIF fields, and so on. Do we encourage them > to have anything in > common with each other's efforts, or just say "use > XML+namespaces, go > invent some named elements and attributes and tell > us what markup > patterns you consider valid". Reinventing the wheel is not necessarily a part of the XML+namespaces approach. Weren't we all just discussing Atom reusing the dcterms:* namespace elements instead of reinventing similar concepts in context of Atom? Similarly, can't I as easily come up with my own RDF based syndication format that doesn't use Dublin Core thus negating all the benefits you claim one gets for free using RDF. It just seems you are advocating that vocabulary designers not reinvent the wheel and reuse other markup vocabularies where possible. Makes sense to me. > If they go the vanilla XML+namespaces route, they > get > to pick some named XML elements and attributes, and > say some stuff about > which element combination patterns are allowed, and > how they can be > decorated with XML attributes. If they go the RDF > route, they don't get > asked which elements theirs can go inside, and which > can go inside > there, **because it isn't up to them**. RDF quite > explicitly witholds that > ability from the creators of a namespace, so that we > don't force people > to anticipate all future uses of their creation, or > get into rigid and > fragile versioning coalitions with owners related > tagsets. (and no, RDF doesn't > solve the namespace versioning problem, but it makes > it approachable, or > at least merely very hard). You've placed restrictions on the XML+namespaces route that actually don't exist in practice as witnessed by the number of RSS extensions as well as their support by numerous clients. > The RDF approach isn't trying to make data > universally understandable in > any fancy AI sense, just universally mixable. If I > want to aggregate jobs > data, I need to know a bit about Jobs-related > namespaces. If I want a > really smart Jobs aggregator, I'll go and > investigate namespaces that > relate to places, to events/time, to skill and topic > description, and to > geography. And I'd be well-advised to create some > nice tools that > actually use that data, and go evangelise those > extensions to parties > who'll create enough feeds to get some adoption. No > magic, just a bit of > structure around a lot of hard work. Again, possible with RSS 2.0 using XML+namespaces based extensibility. It happens all the time today as it is. > > I see this in RSS 2.0 as well. > > RSS 2.0 says "how these namespaces get designed and > how they play > together isn't our problem". Which brings us back to > the scoping > question. If AtomPub's deliverable is really > focussed around weblogging, > then maybe it's OK to say "we don't know yet; maybe > in Version 2". But > if Atom is to be marketed as the backbone for > Web-based data > syndication, establishing a framework that'll serve > us for decades to > come, then the "not our problem" approach to > mixed-namespace design > simply doesn't cut it. Sure. I still await concrete, technical reasons preferably with scenario-driven use cases or examples that show how using RDF based extensibility somehow buys one significantly more than using XML based extensibility on a global, decentralized network like the World Wide Web. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Wed Aug 18 11:56:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16319 for ; Wed, 18 Aug 2004 11:56:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IFk3Gf081036; Wed, 18 Aug 2004 08:46:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IFk3A2081035; Wed, 18 Aug 2004 08:46:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IFk3dq081014 for ; Wed, 18 Aug 2004 08:46:03 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040818154600.99726.qmail@web41206.mail.yahoo.com> Received: from [24.18.136.49] by web41206.mail.yahoo.com via HTTP; Wed, 18 Aug 2004 08:46:00 PDT Date: Wed, 18 Aug 2004 08:46:00 -0700 (PDT) From: Dare Obasanjo Subject: Re: Extensibility in Syndication formats To: Antone Roundy , atom-syntax@imc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Antone Roundy wrote: > > After thinking about this briefly and realizing what > it meant (I > think), this became the single most interesting > point yet to come out > of this discussion. Allow me to make another > example (with some > fanciful elements and structure) to illustrate the > point and see if I > understand it correctly: > > > My title > > Joe > http://www.joe.com/ > > > blue > white > > > > From this, we know that the item has an author and > colors, but what do > the elements inside ... and > ... > describe? The author, or the item? The "colors", > whatever that is, or > the item? We must understand this XML syntax to > know. > > > My title > > Joe > > > > > blue > white > > > Not being very familiar with RDF/XML, I have a > nagging suspicion that > I've done something wrong having the author right > inside the item, but > the point is that now we know that the author's > is referring to > the author, and not the item, and that the > and > colors are referring to the item (or, more > precisely, to the same thing > that the item is referring to), because the > rdf:about URI for > and is the same--they're talking about the > same thing. > > Does that capture a non-trivial part of what RDF > gets us? That we can > tell exactly what each piece of data is talking > about? And as more > extensions are added to make places for more types > of data within an > Atom feed, however they may or may not be nested, we > don't end up > confused about what thing any particular piece of > data is describing? There are several issues with your example. The first is common to all of RDF, using URIs as identifiers is ambiguous (another URI permathread coming up). If I use RDF:about="http://www.microsoft.com", am I talking about the HTML retrieved by performing an HTTP GET of that URL or the actual company Microsoft? Well, it depends on context. If the tagname is I'm probably talking about the markup on the page but if it is I'm probably talking about the company. This goes off into permathread land from here but this example should get the point of why using URI as identifiers is problematic in RDF. Since RDF isn't used much outside closed environments or academic circles you don't hear people complain about this problem much. However if RDF ever gained traction on the World Wide Web, this would be a significant problem. Secondly, XML is all about hierarchies so I fail to see why one would think that an element described its sibling as opposed to its parent element in a markup vocabulary. That is simply not idiomatic XML. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 18 12:14:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18447 for ; Wed, 18 Aug 2004 12:14:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IG0mEu083470; Wed, 18 Aug 2004 09:00:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IG0m8j083467; Wed, 18 Aug 2004 09:00:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IG0l7e083440 for ; Wed, 18 Aug 2004 09:00:48 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 85421 invoked from network); 18 Aug 2004 16:00:47 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.39?) (213.104.222.215) by relay.pair.com with SMTP; 18 Aug 2004 16:00:47 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <41237D2B.9040109@internetalchemy.org> Date: Wed, 18 Aug 2004 17:00:43 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818153540.33046.qmail@web41203.mail.yahoo.com> In-Reply-To: <20040818153540.33046.qmail@web41203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18/08/2004 16:35, Dare Obasanjo wrote: > Before continuing, I'd like to note that besides > [perhaps] NewsMonster of the dozens of RSS aggregators > I have seen in action none treat extensibility in RSS > 1.0 any different from extensibility in RSS 2.0. It's > all just XML and namespaces to them. The other > aggregator authors on the list can pipe up and > disagree with me if I am mistaken. > > Thus the claims of superiority of using RDF-based > extensibility in RSS 1.0 versus using XML + namespaces > as RSS 2.0 does have simply never been shown in the > wild besides the proof of concept stuff that the RDF > syndication usual suspects like Danny Ayers trot out > whenevr this discussion occurs. I wonder how many RSS 2.0 extension modules are actually understood by RSS aggregators. How many does RSS Bandit support for example? Ian From owner-atom-syntax@mail.imc.org Wed Aug 18 12:17:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18622 for ; Wed, 18 Aug 2004 12:17:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IGAB8m084994; Wed, 18 Aug 2004 09:10:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IGABo5084993; Wed, 18 Aug 2004 09:10:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IGAB0Y084962 for ; Wed, 18 Aug 2004 09:10:11 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040818161008.20377.qmail@web41210.mail.yahoo.com> Received: from [24.18.136.49] by web41210.mail.yahoo.com via HTTP; Wed, 18 Aug 2004 09:10:08 PDT Date: Wed, 18 Aug 2004 09:10:08 -0700 (PDT) From: Dare Obasanjo Subject: Re: Extensibility in Syndication formats To: Ian Davis Cc: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org In-Reply-To: <41237D2B.9040109@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > > I wonder how many RSS 2.0 extension modules are > actually understood by > RSS aggregators. How many does RSS Bandit support > for example? We support the following extension elements in an RSS feed - dc:date - dc:author - dc:description - dc:subject - content:encoded - xhtml:body - slash:comments - wfw:comment - wfw:commentRss There might be more but I'd have to look at the code to be sure. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 18 12:41:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20382 for ; Wed, 18 Aug 2004 12:41:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IGQbL3087420; Wed, 18 Aug 2004 09:26:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IGQbBY087419; Wed, 18 Aug 2004 09:26:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IGQaNe087394 for ; Wed, 18 Aug 2004 09:26:36 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 43300 messnum 376722 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 18 Aug 2004 16:26:33 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail05.svc.cra.dublin.eircom.net (qp 43300) with SMTP; 18 Aug 2004 16:26:33 -0000 Message-ID: <41238336.8060509@dehora.net> Date: Wed, 18 Aug 2004 17:26:30 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818154600.99726.qmail@web41206.mail.yahoo.com> In-Reply-To: <20040818154600.99726.qmail@web41206.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > There are several issues with your example. The first > is common to all of RDF, using URIs as identifiers is > ambiguous (another URI permathread coming up). > > If I use RDF:about="http://www.microsoft.com", am I > talking about the HTML retrieved by performing an HTTP > GET of that URL or the actual company Microsoft? Just how is this specific to URIs or RDF? > This goes off into permathread land from here but this > example should get the point of why using URI as > identifiers is problematic in RDF. What identifiers would you suggest? > Since RDF isn't > used much outside closed environments or academic > circles you don't hear people complain about this > problem much. However if RDF ever gained traction on > the World Wide Web, this would be a significant > problem. In no way is the significance of this problem restricted or specific to any technology mentioned in this thread. You argument is vapid. cheers Bill From owner-atom-syntax@mail.imc.org Wed Aug 18 12:51:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21031 for ; Wed, 18 Aug 2004 12:51:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IGZjf6089022; Wed, 18 Aug 2004 09:35:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IGZiIA089021; Wed, 18 Aug 2004 09:35:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-relay-3.tiscali.it (mail-relay-3.tiscali.it [213.205.33.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IGZhnC088799 for ; Wed, 18 Aug 2004 09:35:44 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from virgilio.it (62.11.121.58) by mail-relay-3.tiscali.it (7.1.021.3) id 4111154D00238C70; Wed, 18 Aug 2004 18:35:33 +0200 Message-ID: <4123847F.10008@virgilio.it> Date: Wed, 18 Aug 2004 18:31:59 +0200 From: Danny Ayers Reply-To: danny.ayers@gmail.com User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Robertson CC: atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818082445.62583.qmail@web41202.mail.yahoo.com> <1f2ed5cd04081802471becfcd7@mail.gmail.com> <6.1.2.0.2.20040818094055.025b2a70@www.gosmalltalk.com> In-Reply-To: <6.1.2.0.2.20040818094055.025b2a70@www.gosmalltalk.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Robertson wrote: > > At least in my case, the cost to support that kind of extension is > identical - so RDF buys me nothing. Dan and Bill showed the extensibility angle better than I, concentrating on the ability to mix stuff: [[ The RDF approach isn't trying to make data universally understandable in any fancy AI sense, just universally mixable. ]] But personally I think partial understanding is very cool indeed (but still not fancy ;-). You say the cost to support that kind of extension is identical for you. Ok, add another extension, and another and another. Without a common model you're looking at a cost comparable to the product of the number of extensions. With something above the syntax (even just a low-level entity/relationship model, like the core of RDF) you're looking at something more like a linear increase in cost. Cheers, Danny, -- Raw http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Aug 18 13:16:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23067 for ; Wed, 18 Aug 2004 13:16:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IH9rEf094363; Wed, 18 Aug 2004 10:09:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IH9rQR094362; Wed, 18 Aug 2004 10:09:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IH9pfg094343 for ; Wed, 18 Aug 2004 10:09:51 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040818170949.32418.qmail@web41210.mail.yahoo.com> Received: from [24.18.136.49] by web41210.mail.yahoo.com via HTTP; Wed, 18 Aug 2004 10:09:49 PDT Date: Wed, 18 Aug 2004 10:09:49 -0700 (PDT) From: Dare Obasanjo Subject: Re: Extensibility in Syndication formats To: "Bill_de_hÓra" , atom-syntax@imc.org In-Reply-To: <41238336.8060509@dehora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Bill_de_hÓra wrote: > > > There are several issues with your example. The > first > > is common to all of RDF, using URIs as identifiers > is > > ambiguous (another URI permathread coming up). > > > > If I use RDF:about="http://www.microsoft.com", am > I > > talking about the HTML retrieved by performing an > HTTP > > GET of that URL or the actual company Microsoft? > > Just how is this specific to URIs or RDF? URIs especially HTTP ones are ambiguous. RDF could have come up with a mechanism where it used 1:1 mappings of concepts to identifiers instead of the overloaded and muddy semantics of URIs. This isn't rocket science. > > This goes off into permathread land from here but > this > > example should get the point of why using URI as > > identifiers is problematic in RDF. > > What identifiers would you suggest? I dunno, UUIDs or GUIDs for one. It's not like the identifiers have to be human readable or directly network retrievable. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 18 13:49:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25217 for ; Wed, 18 Aug 2004 13:49:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IHg16R099730; Wed, 18 Aug 2004 10:42:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IHg1UE099729; Wed, 18 Aug 2004 10:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from journurl.com (69-56-184-50.theplanet.com [69.56.184.50] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IHfxs3099694 for ; Wed, 18 Aug 2004 10:42:00 -0700 (PDT) (envelope-from roger@agincourtmedia.com) Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Wed, 18 Aug 2004 12:41:53 -0500 From: "Roger B." To: Subject: RE: Extensibility in Syndication formats Date: Wed, 18 Aug 2004 12:47:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20040818161008.20377.qmail@web41210.mail.yahoo.com> Thread-Index: AcSFPg1Ah6O3dE9FQqmniiX+hxMXqQACwqIw Message-ID: <8998CDC5BFE84B1694288E345690AC.MAI@journurl.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > I wonder how many RSS 2.0 extension modules are > > actually understood by > > RSS aggregators. > > - dc:date > - dc:author > - dc:description > - dc:subject > - content:encoded > - xhtml:body > - slash:comments > - wfw:comment > - wfw:commentRss In addition to the above, Newzcrawler supports annotate:reference At last count, Sharpreader, BottomFeeder, Newsmonster, and WinRSS all support the inclusion of Atom's core elements within RSS via namespaces... atom:content, for example. And according to their marketing materials, Newsgator supports arbitrary extensions as viewable/sortable fields. -- Roger Benningfield JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Wed Aug 18 14:24:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27284 for ; Wed, 18 Aug 2004 14:24:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7II9X0E008564; Wed, 18 Aug 2004 11:09:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7II9XU5008563; Wed, 18 Aug 2004 11:09:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7II9XSu008552 for ; Wed, 18 Aug 2004 11:09:33 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040818180926.93006.qmail@web41213.mail.yahoo.com> Received: from [24.18.136.49] by web41213.mail.yahoo.com via HTTP; Wed, 18 Aug 2004 11:09:26 PDT Date: Wed, 18 Aug 2004 11:09:26 -0700 (PDT) From: Dare Obasanjo Subject: RE: Extensibility in Syndication formats To: "Roger B." , atom-syntax@imc.org In-Reply-To: <8998CDC5BFE84B1694288E345690AC.MAI@journurl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- "Roger B." wrote: > > In addition to the above, Newzcrawler supports > annotate:reference I've been looking for an RSS module for representing USENET posts in feeds. Looks like I found one. RSS Bandit will definitely support this in the next version. Sweet. > At last count, Sharpreader, BottomFeeder, > Newsmonster, and WinRSS all > support the inclusion of Atom's core elements within > RSS via namespaces... > atom:content, for example. You mean they allow arbitrarily mixing different XML vocabularies that were designed in isolation without them having to use RDF? Say it ain't so. :) > And according to their marketing materials, > Newsgator supports arbitrary > extensions as viewable/sortable fields. Although it sounds cool I wonder how many of their users have actually found this functionality useful or used it at all. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 18 14:25:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27319 for ; Wed, 18 Aug 2004 14:25:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IID9YW009178; Wed, 18 Aug 2004 11:13:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IID98m009177; Wed, 18 Aug 2004 11:13:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IID8HD009158 for ; Wed, 18 Aug 2004 11:13:08 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 89725 messnum 7763538 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 18 Aug 2004 18:12:33 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail01.svc.cra.dublin.eircom.net (qp 89725) with SMTP; 18 Aug 2004 18:12:33 -0000 Message-ID: <41239C0E.6050609@dehora.net> Date: Wed, 18 Aug 2004 19:12:30 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818170949.32418.qmail@web41210.mail.yahoo.com> In-Reply-To: <20040818170949.32418.qmail@web41210.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > I dunno, UUIDs or GUIDs for one. It's not like the > identifiers have to be human readable or directly > network retrievable. My point, and I'm not trying to shift the argument towards useless abstractions, is that ambiguity is an issue that transcends choice of identity schemes or models - it's one of those things you learn to put up with it, sort of like latency. Granted inserting further ambiguity a la http: URLs is dubious engineering. But it won't work to suggest if we stop doing that that ambiguity disappears in a puff of logic. For example, I can search replace URI with GUID in the RDF model theory and not alter its semantics, but the scope for ambiguity remains. Here's something I do agree with: for the blogger/aggregator use cases XML+Namespaces plus whatever extensibility recommendations we can take from you or Norm's or Dave's thoughts ought to be sufficient. In reality, unless someone embeds an RDF backed inferencing engine in an /aggregator/, it's all switch blocks and hash maps; RDF won't be leveraged. This is like saying passing relational tables into C# code doesn't mean SQL will get leveraged, iterators will. It's where Atom is taken beyond those use-cases there may be issues; i.e. where people want to be able to reuse atom constructs in such an inferencing context, but it's not clear to me we are 'chartered' for that concern. As for James Robertson's point. If we were sharing smalltalk objects I guess we'd be sorted :) In the meantime I'm not sure how I or your run of the mill DPH can interoperate with or leverage his seemingly excellent object model. So I suppose we need to figure out something for the markup. cheers Bill From owner-atom-syntax@mail.imc.org Wed Aug 18 14:28:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27453 for ; Wed, 18 Aug 2004 14:28:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIFWcA009573; Wed, 18 Aug 2004 11:15:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IIFWYo009572; Wed, 18 Aug 2004 11:15:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIFVZH009554 for ; Wed, 18 Aug 2004 11:15:31 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so231993rnl for ; Wed, 18 Aug 2004 11:15:32 -0700 (PDT) Received: by 10.38.13.31 with SMTP id 31mr538641rnm; Wed, 18 Aug 2004 11:15:32 -0700 (PDT) Message-ID: <14be96d30408181115b84514c@mail.gmail.com> Date: Wed, 18 Aug 2004 14:15:31 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats In-Reply-To: <8998CDC5BFE84B1694288E345690AC.MAI@journurl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8998CDC5BFE84B1694288E345690AC.MAI@journurl.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > > I wonder how many RSS 2.0 extension modules are > > > actually understood by > > > RSS aggregators. > > > > - dc:date http://feedparser.org/docs/reference-entry-modified_parsed.html > > - dc:author http://feedparser.org/docs/reference-entry-author_detail.html > > - dc:description http://feedparser.org/docs/reference-entry-summary_detail.html > > - dc:subject http://feedparser.org/docs/reference-entry-categories.html > > - content:encoded > > - xhtml:body http://feedparser.org/docs/reference-entry-content.html > > - slash:comments > > - wfw:comment > > - wfw:commentRss These are qname-normalized to their defacto "standard" prefix and their values returned as-is: http://feedparser.org/docs/namespace-handling.html -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed Aug 18 14:44:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28457 for ; Wed, 18 Aug 2004 14:44:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIUcYd012594; Wed, 18 Aug 2004 11:30:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IIUcXX012593; Wed, 18 Aug 2004 11:30:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIUbWW012513 for ; Wed, 18 Aug 2004 11:30:37 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7IIWRAX021234; Wed, 18 Aug 2004 14:32:27 -0400 Message-ID: <4123A04D.9020906@intertwingly.net> Date: Wed, 18 Aug 2004 14:30:37 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818161008.20377.qmail@web41210.mail.yahoo.com> In-Reply-To: <20040818161008.20377.qmail@web41210.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > --- Ian Davis wrote: > >>I wonder how many RSS 2.0 extension modules are >>actually understood by >>RSS aggregators. How many does RSS Bandit support >>for example? > > We support the following extension elements in an RSS > feed > > - dc:date > - dc:author > - dc:description > - dc:subject > - content:encoded > - xhtml:body > - slash:comments > - wfw:comment > - wfw:commentRss And admin:errorReportsTo... per http://www.intertwingly.net/blog/2004/04/29/Feedback-loops#c1083248806 - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 18 15:05:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00016 for ; Wed, 18 Aug 2004 15:05:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIoXpm015960; Wed, 18 Aug 2004 11:50:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IIoXYk015959; Wed, 18 Aug 2004 11:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IIoXHV015953 for ; Wed, 18 Aug 2004 11:50:33 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 58021 invoked by uid 17064); 18 Aug 2004 18:50:36 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.4.182]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Aug 2004 18:50:36 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200408181520.BNO36613@ms8.netsolmail.com> References: <200408181520.BNO36613@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <79A87866-F147-11D8-BAC6-000A95D9FA7A@bblfish.net> From: Henry Story Subject: Re: It's about Reading -- not Writing... Date: Wed, 18 Aug 2004 20:50:29 +0200 To: Atom Syntax , "" X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IIoXHV015954 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I added the RSS1.0 feed Dan Brickley mentioned earlier [1] to JNN, my news reader and it read it very well. If you use Protégé it can read any OWL file and even create forms to help people fill them out, even though it is only a machine, and has nothing more to go on than a bunch of rules. If people mix vocabularies that are not of interest to many people then they will soon find out. The best vocabularies will win in a process of natural selection. Atom gains by being able to work on the core of what it is good at, without having to solve every other problem out there too. It does not matter if Atom does not use RDF in the end. It is easy to do: so someone will. Atom itself evolves in a world of standards which go though a process of natural selection. The question was: what does atom bring to the table that RSS did not (other than a better name of course)? If Atom wants to be something big then it should work with the rest of the world, in a distributed manner. Then it will leverage the best thinkers around the world. Otherwise it is just a slightly better Arse feed. And though it might be a standard on paper, people may well wonder what the big deal about it was. Henry [1] http://www.nature.com/naturejobs/jobs/biologicalsciences.rdf On 18 Aug 2004, at 17:20, Bob Wyman wrote: > > If a message is written but never read, was anything communicated? > If a tree falls in a forest... > [...] > From owner-atom-syntax@mail.imc.org Wed Aug 18 15:34:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01797 for ; Wed, 18 Aug 2004 15:34:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJMDU4021833; Wed, 18 Aug 2004 12:22:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJMDYO021832; Wed, 18 Aug 2004 12:22:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJMA32021784 for ; Wed, 18 Aug 2004 12:22:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01139; Wed, 18 Aug 2004 15:21:12 -0400 (EDT) Message-Id: <200408181921.PAA01139@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-autodiscovery-00.txt Date: Wed, 18 Aug 2004 15:21:12 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : Atom Feed Autodiscovery Author(s) : M. Pilgrim Filename : draft-ietf-atompub-autodiscovery-00.txt Pages : 14 Date : 2004-8-18 This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-autodiscovery-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-ietf-atompub-autodiscovery-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-ietf-atompub-autodiscovery-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-18142939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-autodiscovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-autodiscovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-18142939.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Wed Aug 18 15:47:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03182 for ; Wed, 18 Aug 2004 15:47:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJT8m6023054; Wed, 18 Aug 2004 12:29:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJT885023047; Wed, 18 Aug 2004 12:29:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IJT77O023022 for ; Wed, 18 Aug 2004 12:29:07 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 13966 invoked from network); 18 Aug 2004 19:29:08 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.39?) (213.104.222.215) by relay.pair.com with SMTP; 18 Aug 2004 19:29:08 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <4123ADFD.50502@internetalchemy.org> Date: Wed, 18 Aug 2004 20:29:01 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818161008.20377.qmail@web41210.mail.yahoo.com> In-Reply-To: <20040818161008.20377.qmail@web41210.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18/08/2004 17:10, Dare Obasanjo wrote: > We support the following extension elements in an RSS > feed > > - dc:date > - dc:author > - dc:description > - dc:subject > - content:encoded > - xhtml:body > - slash:comments > - wfw:comment > - wfw:commentRss > > There might be more but I'd have to look at the code > to be sure. Anything more complex than single elements e.g. threading or embedded creative commons licenses? If so, how many lines of code does the parsing of those extensions take? Ian From owner-atom-syntax@mail.imc.org Wed Aug 18 15:57:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05268 for ; Wed, 18 Aug 2004 15:57:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJcWg5025017; Wed, 18 Aug 2004 12:38:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJcWix025016; Wed, 18 Aug 2004 12:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IJcWka024987 for ; Wed, 18 Aug 2004 12:38:32 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040818193831.63691.qmail@web41210.mail.yahoo.com> Received: from [24.18.136.49] by web41210.mail.yahoo.com via HTTP; Wed, 18 Aug 2004 12:38:31 PDT Date: Wed, 18 Aug 2004 12:38:31 -0700 (PDT) From: Dare Obasanjo Subject: Re: Extensibility in Syndication formats To: Ian Davis Cc: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org In-Reply-To: <4123ADFD.50502@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > On 18/08/2004 17:10, Dare Obasanjo wrote: > > We support the following extension elements in an > RSS > > feed > > > > - dc:date > > - dc:author > > - dc:description > > - dc:subject > > - content:encoded > > - xhtml:body > > - slash:comments > > - wfw:comment > > - wfw:commentRss > > > > There might be more but I'd have to look at the > code > > to be sure. > Anything more complex than single elements e.g. > threading or embedded > creative commons licenses? I'm not sure what is meant by this question. Are you asking if I support any elements that are have complex content (attributes + child elements) as extensions? If so the answer is no. > If so, how many lines of code does the parsing of > those extensions take? Parsing out the content of the element based on its name takes the same 4 - 8 lines of code. However what ends up being done with the extension varies very wildly. The code to retrieve the comment RSS feed is a lot more complex than that to display the dc:subject value of an item for example. I'm not sure what kind of reasonable comparison can be made here. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 18 16:10:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07958 for ; Wed, 18 Aug 2004 16:10:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJxfiT028537; Wed, 18 Aug 2004 12:59:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJxfc4028536; Wed, 18 Aug 2004 12:59:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IJxeiO028516 for ; Wed, 18 Aug 2004 12:59:40 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 42880 invoked from network); 18 Aug 2004 19:59:00 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.39?) (213.104.222.215) by relay.pair.com with SMTP; 18 Aug 2004 19:59:00 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <4123B4FF.6010706@internetalchemy.org> Date: Wed, 18 Aug 2004 20:58:55 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818193831.63691.qmail@web41210.mail.yahoo.com> In-Reply-To: <20040818193831.63691.qmail@web41210.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18/08/2004 20:38, Dare Obasanjo wrote: >>Anything more complex than single elements e.g. >>threading or embedded >>creative commons licenses? > > > I'm not sure what is meant by this question. Are you > asking if I support any elements that are have complex > content (attributes + child elements) as extensions? > If so the answer is no. I think there's a complexity difference between single element extensions that appear as children of the primary elements (e.g. channel/item/feed/entry) and complex structures such as creative commons where you may want to embed a description of a custom license. Parsing the former is just a few lines of code, the latter may add much more complexity since you need to store parent element context as you descend the markup tree. I'm not talking about implementing the effects of the extension - obviously that differs widely depending on the semantics. Adopting a standard syntactical structure for extension modules means readers can have one standard parsing component that can parse Atom plus any combination of extensions into a queryable data model. Ian From owner-atom-syntax@mail.imc.org Wed Aug 18 16:52:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15210 for ; Wed, 18 Aug 2004 16:52:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKh1ZX035199; Wed, 18 Aug 2004 13:43:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IKh12g035198; Wed, 18 Aug 2004 13:43:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IKguN5035161 for ; Wed, 18 Aug 2004 13:42:56 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040818204255.73722.qmail@web41209.mail.yahoo.com> Received: from [24.18.136.49] by web41209.mail.yahoo.com via HTTP; Wed, 18 Aug 2004 13:42:55 PDT Date: Wed, 18 Aug 2004 13:42:55 -0700 (PDT) From: Dare Obasanjo Subject: Re: Extensibility in Syndication formats To: Ian Davis Cc: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org In-Reply-To: <4123B4FF.6010706@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > > I think there's a complexity difference between > single element > extensions that appear as children of the primary > elements (e.g. > channel/item/feed/entry) and complex structures such > as creative commons > where you may want to embed a description of a > custom license. > > Parsing the former is just a few lines of code, the > latter may add much > more complexity since you need to store parent > element context as you > descend the markup tree. I'm not talking about > implementing the effects > of the extension - obviously that differs widely > depending on the semantics. You are assuming all sorts of things about what the implementation does. For example, a DOM based implementation wouldn't have these issues you claim. And in fact, all versions of RSS Bandit have used a DOM for parsing XML and I recently changed this just a few weeks but haven't shipped this change in a release yet. > Adopting a standard syntactical structure for > extension modules means > readers can have one standard parsing component that > can parse Atom plus > any combination of extensions into a queryable data > model. The way the RSS Bandit code is written it doesn't matter if unknown extensions are simple or complex content. So I wouldn't benefit from or be harmed by a decision such as this. I personally find it unnecessarily limiting just to potentially save a few lines of fairly straightforward code in aggregators. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 18 16:59:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16150 for ; Wed, 18 Aug 2004 16:59:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKoUrV036316; Wed, 18 Aug 2004 13:50:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IKoUOk036315; Wed, 18 Aug 2004 13:50:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7IKoUtM036300 for ; Wed, 18 Aug 2004 13:50:30 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 95005 invoked from network); 18 Aug 2004 20:50:22 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.39?) (213.104.222.215) by relay.pair.com with SMTP; 18 Aug 2004 20:50:22 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <4123C109.1020800@internetalchemy.org> Date: Wed, 18 Aug 2004 21:50:17 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818204255.73722.qmail@web41209.mail.yahoo.com> In-Reply-To: <20040818204255.73722.qmail@web41209.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18/08/2004 21:42, Dare Obasanjo wrote: > The way the RSS Bandit code is written it doesn't > matter if unknown extensions are simple or complex > content. So I wouldn't benefit from or be harmed by a > decision such as this. I personally find it > unnecessarily limiting just to potentially save a few > lines of fairly straightforward code in aggregators. Fair enough. I, personally, would prefer not to have to write new parsing code with associated data structure every time I want to support a new extension. I'd rather focus on the extension behaviour than its syntax. Ian From owner-atom-syntax@mail.imc.org Wed Aug 18 17:00:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16319 for ; Wed, 18 Aug 2004 17:00:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKqbIq036717; Wed, 18 Aug 2004 13:52:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IKqbgU036716; Wed, 18 Aug 2004 13:52:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKqaXY036690; Wed, 18 Aug 2004 13:52:36 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BxXQ3-0004RZ-L6; Wed, 18 Aug 2004 20:52:27 +0000 Message-ID: <4123C185.3020307@franklinmint.fm> Date: Wed, 18 Aug 2004 16:52:21 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Davis CC: Dare Obasanjo , Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818193831.63691.qmail@web41210.mail.yahoo.com> <4123B4FF.6010706@internetalchemy.org> In-Reply-To: <4123B4FF.6010706@internetalchemy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > > I think there's a complexity difference between single element > extensions that appear as children of the primary elements (e.g. > channel/item/feed/entry) and complex structures such as creative commons > where you may want to embed a description of a custom license. > If a given structure is really complex, it probably doesn't belong in a syndication feed as metadata. A reference to an external resource would be fine [0]. If you really want to include it, there's nothing stopping you from using an extension consisting of RDF/XML. There are a limited number of subjects in an Atom Entry. A general-purpose model like RDF seems like total overkill to me. However, that's just opinion. We're here to standardize current practice, so let's see some examples of complex RDF extensions succeeding in syndication. For example, how widely used is the "rich" variant of the RSS1.0 DC module? Robert Sayre [0] http://backend.userland.com/discuss/msgReader$200 From owner-atom-syntax@mail.imc.org Wed Aug 18 17:09:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17482 for ; Wed, 18 Aug 2004 17:09:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKvjou037502; Wed, 18 Aug 2004 13:57:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IKvjUg037501; Wed, 18 Aug 2004 13:57:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKviUb037494 for ; Wed, 18 Aug 2004 13:57:44 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Wed, 18 Aug 2004 13:57:48 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: ID wording Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. Thanks for keeping the moratorium on ID discussion. I thought it would be best to do a sanity check to be sure people were in agreement on what it seems the consensus so far was. - The format for IDs is going to be URIs, not plain strings. - IDs must not change over time. - Even though the format is a URI, the IDs are not expected to be dereferencable (although they might be). - IDs MUST be compared character-by-character, no case-mapping, no %xx conversion, and so on. - Receiving and gateway systems MUST NOT alter IDs in any way. - Because IDs might be dereferenced, and because they must not be changed, it is a good idea to create them in a canonicalized form. There is no interoperability issues with this suggestion, so it is just a suggestion, not a SHOULD-level suggestion. Does this match what people feel was the general consensus? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 18 17:23:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20306 for ; Wed, 18 Aug 2004 17:23:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILFPfA040483; Wed, 18 Aug 2004 14:15:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ILFPG3040482; Wed, 18 Aug 2004 14:15:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILFOhY040461 for ; Wed, 18 Aug 2004 14:15:25 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id DF0437C2E8; Thu, 19 Aug 2004 00:07:20 +0200 (CEST) Date: Wed, 18 Aug 2004 23:17:01 +0200 To: "Angus Turnbull" Subject: Re: Distributed comment/post authorisation proposal Cc: Atom-Syntax References: <002a01c484ca$4b051120$eb01a8c0@nirvana> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <002a01c484ca$4b051120$eb01a8c0@nirvana> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 18 Aug 2004 14:23:02 +1200, Angus Turnbull wrote: > However, it would be possible to add functionality to host an > authorisation server as a CGI script on your own domain (or a provider > of your choice) that would allow you to post comments/articles on other > blogs, authenticated as yourself, without giving personal information to > the blog owner. Think of Microsoft Passport done via an open-standard > API for blogging. I would assume that the Liberty Alliance Project[1] is what you want. What I want too, for that matter. It is a great idea that opens up for a much more (user-) friendly web. It also makes it a lot simpler to know who you can trust, since it creates so called «trusted networks» or «circles of trust» within a group of people that trusts each other. Let's say that you trust Mark Pilgrim, and thus have his public key in your whitelist. Sam Ruby also trusts Mark Pilgrim, so he's in his whitelist as well. If Tim Bray trusts Sam and you, but have never heard of Mark, Mark would still have high credibility since two of Tim's trusted friends trust him. However, if I, who aren't trusted by anyone, tries to write to Tim's blog, my posts will be appended to a queue, since Tim has no idea about my credibility. Whenever I prove myself worthy of his trust, my comments will go directly out to the blog. I've thought about this idea for quite a while, and I think Atom is the perfect technology to test such a technology out with. ____ [1] -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 18 17:24:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20544 for ; Wed, 18 Aug 2004 17:24:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILHdWp040826; Wed, 18 Aug 2004 14:17:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ILHdNm040825; Wed, 18 Aug 2004 14:17:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode01.zonnet.nl (postbode01.zonnet.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILHaYb040782 for ; Wed, 18 Aug 2004 14:17:38 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 27266 invoked by uid 10); 18 Aug 2004 21:17:33 -0000 Received: (vexira-qq 27260-3DDED6AF invoked from network) 18 Aug 2004 23:17:33 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode01.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 18 Aug 2004 21:17:33 -0000 Message-ID: <4123C76E.10706@annevankesteren.nl> Date: Wed, 18 Aug 2004 23:17:34 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: Re: Atom Feed Autodiscovery draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.19; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Greetings again. As you saw a little while ago, there is a new draft in > the WG on autodiscovery. Although it is not on the WG's issues list > (), it is > perfectly reasonable to discuss it here. I still get a 404 for that draft, but I guess I have to wait a little while, just like last time. Correct? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Wed Aug 18 17:27:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20770 for ; Wed, 18 Aug 2004 17:27:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILDKAU040048; Wed, 18 Aug 2004 14:13:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ILDKvr040047; Wed, 18 Aug 2004 14:13:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILDI02040040 for ; Wed, 18 Aug 2004 14:13:19 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Wed, 18 Aug 2004 14:13:23 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Atom Feed Autodiscovery draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. As you saw a little while ago, there is a new draft in the WG on autodiscovery. Although it is not on the WG's issues list (), it is perfectly reasonable to discuss it here. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 18 17:42:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22619 for ; Wed, 18 Aug 2004 17:42:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILUrq5042846; Wed, 18 Aug 2004 14:30:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ILUrdw042845; Wed, 18 Aug 2004 14:30:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILUqif042838 for ; Wed, 18 Aug 2004 14:30:52 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7ILWjtW029985 for ; Wed, 18 Aug 2004 17:32:45 -0400 Message-ID: <4123CA8F.70206@intertwingly.net> Date: Wed, 18 Aug 2004 17:30:55 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: NoInventions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Not that all moratoriums are lifted, I've been quietly working on a series of paces which attempts to streamline and tighten a number of children of atom:entry elements: http://www.intertwingly.net/wiki/pie/NoInventions Note: this are paces I've authored as a member of the working group, I'm not presenting this in my role as secretary. Also, these are not a package, each Pace can be evaluated independently. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 18 17:51:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23187 for ; Wed, 18 Aug 2004 17:51:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILQIgf042161; Wed, 18 Aug 2004 14:26:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ILQINI042160; Wed, 18 Aug 2004 14:26:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ILQE08042148; Wed, 18 Aug 2004 14:26:15 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4123C76E.10706@annevankesteren.nl> References: <4123C76E.10706@annevankesteren.nl> Date: Wed, 18 Aug 2004 14:26:19 -0700 To: Anne van Kesteren From: Paul Hoffman / IMC Subject: Re: Atom Feed Autodiscovery draft Cc: Atom WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:17 PM +0200 8/18/04, Anne van Kesteren wrote: >>Greetings again. As you saw a little while ago, there is a new >>draft in the WG on autodiscovery. Although it is not on the WG's >>issues list >>(), it is >>perfectly reasonable to discuss it here. > >I still get a 404 for that draft, but I guess I have to wait a >little while, just like last time. Correct? Probably correct. The IETF Secretariat is *supposed* to have the drafts available before sending the mail, but sometimes don't. I'll nudge them again about this. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 18 18:19:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26214 for ; Wed, 18 Aug 2004 18:19:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IM7gPF049230; Wed, 18 Aug 2004 15:07:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IM7gXd049229; Wed, 18 Aug 2004 15:07:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IM7fqF049222 for ; Wed, 18 Aug 2004 15:07:41 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7IM7k53011684 for ; Wed, 18 Aug 2004 16:07:46 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2N003I4XGXQU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 18 Aug 2004 16:07:46 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2N00KA1XGX3N@mail.sun.net> for atom-syntax@imc.org; Wed, 18 Aug 2004 16:07:45 -0600 (MDT) Date: Wed, 18 Aug 2004 15:07:54 -0700 From: Tim Bray Subject: Next step on Dates To: Atom WG Message-id: <0E0F1F40-F163-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT OK, it's time for us to try to push the the infamous "dates" issue along one more step. Frankly, I would never have predicted how hard this was going to be. Here's what I think we learned as a result of the last go-around: 1. There is consensus behind at least one date in atom:entry. 2. There is support for a variety of combinations of dates, but with distressingly little consensus on the combinations or the semantics of the individual dates. 3. There are more problems than we'd appreciated in calling out to the Dublin Core dates. The problem is that the lack of consensus puts us at risk of getting *no* dates in Atom. Which I think we can agree would be a mistake. So I think our next step is to try to push one or maybe more date elements across the goal line, where the goal line for some date proposal is defined as a significant number of people speaking up to say they want it in Atom and a relatively small number of people saying they'd rather not have it, and ideally almost nobody saying it's disastrous and they can't live with it. I'm sorry, this definition of consensus is "rough" indeed, but I suspect it's the best we're going to get on this topic (I believe most other issues will be less work). So, concretely, here are the steps: 1. All the current Date* paces are closed. They were useful, and thanks to those who wrote them. 2. We encourage the submission of a new round of Paces, each proposing a single date for acceptance in Atom. The date should have a name, i.e. not "a", "b", "c". The name of the Pace is not significant, so try to avoid anything controversial or semantically loaded. No suggestion will be taken seriously unless it contains expressions of support from at least three people who have been active on the list - this is to prevent us from wasting time on suggestions that have little chance of achieving consensus. Please only solicit support for your proposals in private correspondence. 3. Repeat: Each Pace can only propose *one* date. 4. When we get the next round of single-date Paces, we'll give each one a chance to get over the goal line as defined above. This is going to work best if we can consider the proposals independently, i.e. they preclude each other as little as possible. The issue of whether we make any mention of the dc: dates will be treated for the moment as orthogonal and we'll take it up later. Let's get the new round of Paces in by the end of Monday the 23rd, and see if we can put this to bed next week. Yes, this is all feels like more work than it ought to be, but we've gotta get through this one way or another. -Tim From owner-atom-syntax@mail.imc.org Wed Aug 18 19:20:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29582 for ; Wed, 18 Aug 2004 19:20:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INAVC0059190; Wed, 18 Aug 2004 16:10:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INAVmT059189; Wed, 18 Aug 2004 16:10:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INAUeh059166 for ; Wed, 18 Aug 2004 16:10:30 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <20040818231030013005sci7e>; Wed, 18 Aug 2004 23:10:31 +0000 Date: Wed, 18 Aug 2004 17:10:29 -0600 Subject: Re: Next step on Dates Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <0E0F1F40-F163-11D8-99EE-000A95A51C9E@sun.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've been a little surprised at the near total lack of response to Sam's "Accuracy and Precision in dates"[1], so I'll bring it up again. Here's the executive summary of my response[2]: Questions: 1) What are we trying to accomplish with dates in Atom? 2) What Date Construct definition(s) would maximize our ability to accomplish that? Possible answers: To #1: A) Enable a desirable sort order B) Provide a meaningful display date To #2: The following 2: I) "Updated"--the objective date of the most recent modification which the publisher subjectively decided was significant enough to highlight. II) A subjective "display" date. FAQ: i) "What if I want to sort by 'Issued'?" You can get close enough (see Sam's email[1]) by caching "Updated" the first time you see an entry, and continue to sort by that value even if the publisher modifies "Updated". ii) "What if I don't want to change the date in my feed, even if I make a huge modification?" Fine. Don't change it. You've subjectively decided not to highlight the change, so the unchanged date fits the specification. Antone [1] http://www.imc.org/atom-syntax/mail-archive/msg08457.html [2] http://www.imc.org/atom-syntax/mail-archive/msg08458.html ======================================= P.S. If this all sounds reasonable to you, see PaceDateAntoneRoundy2[3], which never seems to have made it on to the issues list, and the announcement of which, in another surprise to me, garnered a similar amount of discussion as "Accuracy and Precision in dates". The following is an except from a response I sent to an offline message about this proposal: > I think there are a number of different axes along which people are > divided. I think the proposal deals with a lot of the conflicts in a > way that I HOPE will make it possible to build consensus: > > * In the core vs. by reference: we define something in the core which > should cover most uses, but welcome people to use extensions to do > other things if they want to (which they always were welcome to do). > > * Duplication in the core of the things we think are most important > from dcterms vs. no duplication: no duplication, but a clear pointer > toward where to find the things that have already been defined in > dcterms if you need them. > > * Consumers HAVE TO be able to deal with a lot of dates, any of which > may or may not be present vs. keep the requirements simple: Keeps the > requirements simple, but points the way clearly for people who want to > do more complex things. > > * Have a clear way to specify a variety of time stamps vs. just bail > and stick with something not much better than RSS because it's too > hard to find consensus: bail on building the specific stuff into the > core, but provide a clear pointer for how to specify that stuff if you > want to. [3] http://www.intertwingly.net/wiki/pie/PaceDateAntoneRoundy2 From owner-atom-syntax@mail.imc.org Wed Aug 18 19:53:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01292 for ; Wed, 18 Aug 2004 19:53:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INaW86063394; Wed, 18 Aug 2004 16:36:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INaVvH063392; Wed, 18 Aug 2004 16:36:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INaV7V063363 for ; Wed, 18 Aug 2004 16:36:31 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so197715rnl for ; Wed, 18 Aug 2004 16:36:25 -0700 (PDT) Received: by 10.38.92.44 with SMTP id p44mr567710rnb; Wed, 18 Aug 2004 16:36:25 -0700 (PDT) Message-ID: <3f1451f504081816367df8dd05@mail.gmail.com> Date: Wed, 18 Aug 2004 19:36:25 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Paul Hoffman / IMC Subject: Re: ID wording Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 18 Aug 2004 13:57:48 -0700, Paul Hoffman / IMC wrote: > > Greetings again. Thanks for keeping the moratorium on ID discussion. > I thought it would be best to do a sanity check to be sure people > were in agreement on what it seems the consensus so far was. > > - The format for IDs is going to be URIs, not plain strings. > > - IDs must not change over time. > > - Even though the format is a URI, the IDs are not expected to be > dereferencable (although they might be). > > - IDs MUST be compared character-by-character, no case-mapping, no > %xx conversion, and so on. > > - Receiving and gateway systems MUST NOT alter IDs in any way. > > - Because IDs might be dereferenced, and because they must not be > changed, it is a good idea to create them in a canonicalized form. > There is no interoperability issues with this suggestion, so it is > just a suggestion, not a SHOULD-level suggestion. > > Does this match what people feel was the general consensus? +1 -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Aug 18 20:01:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02215 for ; Wed, 18 Aug 2004 20:01:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INoUAb065566; Wed, 18 Aug 2004 16:50:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INoU4a065565; Wed, 18 Aug 2004 16:50:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INoT9W065559 for ; Wed, 18 Aug 2004 16:50:29 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7INqM5L004305; Wed, 18 Aug 2004 19:52:23 -0400 Message-ID: <4123EB48.7000508@intertwingly.net> Date: Wed, 18 Aug 2004 19:50:32 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: Next step on Dates References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > I've been a little surprised at the near total lack of response to Sam's > "Accuracy and Precision in dates"[1], so I'll bring it up again. Here's > the executive summary of my response[2]: > > Questions: > 1) What are we trying to accomplish with dates in Atom? > 2) What Date Construct definition(s) would maximize our ability to > accomplish that? > > Possible answers: > To #1: > A) Enable a desirable sort order > B) Provide a meaningful display date Something to think about: typically one provides a means to display the date upon which you sort. http://www.intertwingly.net/wiki/pie/PaceDateElement - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 18 21:48:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06644 for ; Wed, 18 Aug 2004 21:48:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J1ZPd2081022; Wed, 18 Aug 2004 18:35:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J1ZPI9081021; Wed, 18 Aug 2004 18:35:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta206-rme.xtra.co.nz (mta206-rme.xtra.co.nz [210.86.15.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J1ZOMh080999 for ; Wed, 18 Aug 2004 18:35:24 -0700 (PDT) (envelope-from angus@twinhelix.com) Received: from mta7-rme.xtra.co.nz ([210.86.15.141]) by mta206-rme.xtra.co.nz with ESMTP id <20040819013519.OMWW25634.mta206-rme.xtra.co.nz@mta7-rme.xtra.co.nz>; Thu, 19 Aug 2004 13:35:19 +1200 Received: from nirvana ([222.152.134.183]) by mta7-rme.xtra.co.nz with SMTP id <20040819013518.ECJK9663.mta7-rme.xtra.co.nz@nirvana>; Thu, 19 Aug 2004 13:35:18 +1200 Message-ID: <009901c4858c$c3328480$eb01a8c0@nirvana> From: "Angus Turnbull" To: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: "Atom-Syntax" References: <002a01c484ca$4b051120$eb01a8c0@nirvana> Subject: Re: Distributed comment/post authorisation proposal Date: Thu, 19 Aug 2004 13:35:05 +1200 Organization: TwinHelix Designs - http://www.twinhelix.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7J1ZPMh081011 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > I would assume that the Liberty Alliance Project[1] is what you want. > What I want too, for that matter. > > It is a great idea that opens up for a much more (user-) friendly > web. It also makes it a lot simpler to know who you can trust, since > it creates so called «trusted networks» or «circles of trust» within > a group of people that trusts each other. > > Let's say that you trust Mark Pilgrim, and thus have his public key in > your whitelist. Sam Ruby also trusts Mark Pilgrim, so he's in his > whitelist as well. If Tim Bray trusts Sam and you, but have never > heard of Mark, Mark would still have high credibility since two of > Tim's trusted friends trust him. > > However, if I, who aren't trusted by anyone, tries to write to Tim's > blog, my posts will be appended to a queue, since Tim has no idea > about my credibility. Whenever I prove myself worthy of his trust, my > comments will go directly out to the blog. > > I've thought about this idea for quite a while, and I think Atom is > the perfect technology to test such a technology out with. > > ____ > [1] Indeed, I'm aware of the Liberty Alliance. This is a simpler protocol change native to the ATOM API that doesn't rely on a distributed network of trust, something I feel would be really, really contentious to implement given the existing RDF vs. XML Schema flamewars on this list! It seems my initial post has virtually sunk without a trace. Is it considered unworkable? Personally, I think it could be a "killer app" of ATOM syndication, as to be honest, end-users don't really notice or care whether their aggregator is using RSS 0.9x, 1.0, 2.0, ATOM or whatever, just as long as it works. Basically, being able to post an authenticated comment from within your aggregator of choice on any compliant blog would be a really distinguishing feature. Putting in some smart server-to-server authorisation protocols could well lead to a distributed trust/FOAF type network regardless, as a natural evolution of the protocol. Anyway, I'm out of here for now. I just wanted to float the idea and see what happened. Hopefully one or other kind of distributed authorisation eventually makes it into the ATOM proposal. Good luck if you do want to push a FOAF approach! From owner-atom-syntax@mail.imc.org Wed Aug 18 22:15:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08081 for ; Wed, 18 Aug 2004 22:15:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J20ktb084707; Wed, 18 Aug 2004 19:00:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J20k13084706; Wed, 18 Aug 2004 19:00:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J20h5A084648 for ; Wed, 18 Aug 2004 19:00:45 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 19 Aug 2004 12:06:24 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 Aug 2004 11:59:38 +1000 Subject: Re: ID wording From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 19/8/04 6:57 AM, "Paul Hoffman / IMC" wrote: > what it seems the consensus so far was. > > - The format for IDs is going to be URIs, not plain strings. > > - IDs must not change over time. > > - Even though the format is a URI, the IDs are not expected to be > dereferencable (although they might be). > > - IDs MUST be compared character-by-character, no case-mapping, no > %xx conversion, and so on. > > - Receiving and gateway systems MUST NOT alter IDs in any way. > > - Because IDs might be dereferenced, and because they must not be > changed, it is a good idea to create them in a canonicalized form. > There is no interoperability issues with this suggestion, so it is > just a suggestion, not a SHOULD-level suggestion. > > Does this match what people feel was the general consensus? +1 From owner-atom-syntax@mail.imc.org Wed Aug 18 22:36:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10359 for ; Wed, 18 Aug 2004 22:36:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J2GEcY086942; Wed, 18 Aug 2004 19:16:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J2GETA086941; Wed, 18 Aug 2004 19:16:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fl-mta02.durocom.com (fl-mta02.durocom.com [216.53.195.243]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J2GDfF086923 for ; Wed, 18 Aug 2004 19:16:13 -0700 (PDT) (envelope-from jarober@gosmalltalk.com) Received: from james2.gosmalltalk.com ([66.90.11.38]) by fl-mta02.durocom.com with ESMTP id <20040819021616.HPKK27248.fl-mta02@james2.gosmalltalk.com> for ; Wed, 18 Aug 2004 22:16:16 -0400 Message-Id: <6.1.2.0.2.20040818221329.02bd17a0@www.gosmalltalk.com> X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 18 Aug 2004 22:15:54 -0400 To: atom-syntax@imc.org From: James Robertson Subject: Re: Extensibility in Syndication formats In-Reply-To: <41237D2B.9040109@internetalchemy.org> References: <20040818153540.33046.qmail@web41203.mail.yahoo.com> <41237D2B.9040109@internetalchemy.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: BottomFeeder handles 15 of them at the moment >I wonder how many RSS 2.0 extension modules are actually understood by RSS >aggregators. How many does RSS Bandit support for example? > >Ian > > James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView jarober@gosmalltalk.com From owner-atom-syntax@mail.imc.org Thu Aug 19 00:13:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14936 for ; Thu, 19 Aug 2004 00:13:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J3vLx4002118; Wed, 18 Aug 2004 20:57:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J3vLeR002117; Wed, 18 Aug 2004 20:57:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J3vDBX002096 for ; Wed, 18 Aug 2004 20:57:16 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 19 Aug 2004 14:03:43 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 Aug 2004 13:27:22 +1000 Subject: Re: Syndication of updates and deletions of content From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18/8/04 11:30 PM, "Pier Fumagalli" wrote: > Good point... Maybe just and are actually pertinent to > the notification of a removal event. A delete event fits within the rubric of a full versioning publishing process, and sits alongside other events like retracted, superceded, withdrawn, etc. If I had a situation where I wanted to "delete" some entry I've published, I'd probably do something like this: ... DELETED! Sorry, someone threatened me with a kneecapping ... This raises a question for me though ... if version#1 contains some elements, but version#2 is missing some of those elements, does this mean that the true entry is in fact missing those elements? If so, will this bork the SSFF profile of atom? e. From owner-atom-syntax@mail.imc.org Thu Aug 19 00:51:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16466 for ; Thu, 19 Aug 2004 00:51:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J4anGO007039; Wed, 18 Aug 2004 21:36:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J4anwT007035; Wed, 18 Aug 2004 21:36:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J4amSU007025; Wed, 18 Aug 2004 21:36:49 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 9626C4EFD1; Thu, 19 Aug 2004 00:36:54 -0400 (EDT) Message-Id: <4.2.0.58.J.20040819130936.05e98a80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 19 Aug 2004 13:09:55 +0900 To: Paul Hoffman / IMC , Atom WG From: Martin Duerst Subject: Re: ID wording In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Very good summary. +1. Reagrds, Martin. At 13:57 04/08/18 -0700, Paul Hoffman / IMC wrote: >Greetings again. Thanks for keeping the moratorium on ID discussion. I >thought it would be best to do a sanity check to be sure people were in >agreement on what it seems the consensus so far was. > >- The format for IDs is going to be URIs, not plain strings. > >- IDs must not change over time. > >- Even though the format is a URI, the IDs are not expected to be >dereferencable (although they might be). > >- IDs MUST be compared character-by-character, no case-mapping, no %xx >conversion, and so on. > >- Receiving and gateway systems MUST NOT alter IDs in any way. > >- Because IDs might be dereferenced, and because they must not be changed, >it is a good idea to create them in a canonicalized form. There is no >interoperability issues with this suggestion, so it is just a suggestion, >not a SHOULD-level suggestion. > >Does this match what people feel was the general consensus? > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 19 01:12:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17238 for ; Thu, 19 Aug 2004 01:12:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J4uqTF009636; Wed, 18 Aug 2004 21:56:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J4uquv009635; Wed, 18 Aug 2004 21:56:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J4uqIL009625; Wed, 18 Aug 2004 21:56:52 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7J4uxIV029973; Wed, 18 Aug 2004 21:56:59 -0700 (PDT) Received: from [192.168.0.3] (70-56-171-39.mpls.qwest.net [70.56.171.39]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i7J4uwK5015650; Wed, 18 Aug 2004 21:56:59 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-767584558; protocol="application/pkcs7-signature" Message-Id: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> Cc: Atom WG From: Graham Subject: Re: ID wording Date: Wed, 18 Aug 2004 23:56:57 -0500 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-1-767584558 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 18 Aug 2004, at 3:57 pm, Paul Hoffman / IMC wrote: > - The format for IDs is going to be URIs, not plain strings. > - IDs must not change over time. > - Even though the format is a URI, the IDs are not expected to be > dereferencable (although they might be). > - IDs MUST be compared character-by-character, no case-mapping, no %xx > conversion, and so on. > - Receiving and gateway systems MUST NOT alter IDs in any way. > - Because IDs might be dereferenced, and because they must not be > changed, it is a good idea to create them in a canonicalized form. > There is no interoperability issues with this suggestion, so it is > just a suggestion, not a SHOULD-level suggestion. Absolutely - see, that wasn't hard, was it? That's where the consensus has always been. (I still don't understand the case for canonicalized ids - is there some reason for it beyond gateways that accidentally canonicalize not doing any damage?) Graham --Apple-Mail-1-767584558 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODE5MDQ1NjU4WjAjBgkqhkiG9w0BCQQxFgQUfgo//Xt3sOukYBqhfHV26GI/ X8sweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAxkyo/tFtpqw1Y2vlX3qzgde8 pQG0tKeyZ1Mtgp4AqeMm2QocX878V6SFnLfZSkvPJ2Xv1ijiD+qJSC9rTk/SKQNA54lOXlGr9n+5 +Hto3K1uGEyxTxdHs9qQc1uJXQBQwjh+AC2Vt+z/hEB988BIvoZgr0kOGD6eTxIYnypjmkYXW2CM YGXA44HbfCbYBLuV5miztpF7I+xgwkJQQvpKSrZWACVA4JADwjAyA+xtKx1nIM5Js6Z/mP1RntZV S4xtWc9weYGEt0ti+Wf/SE3rPxh62gOKRtmoz07jo5uRsd8pIA4sc7ebW0CtCCNuaSFUDoJdHcHK L/VR/16+XgeYawAAAAAAAA== --Apple-Mail-1-767584558-- From owner-atom-syntax@mail.imc.org Thu Aug 19 01:30:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17970 for ; Thu, 19 Aug 2004 01:30:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J5H3Qd013597; Wed, 18 Aug 2004 22:17:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J5H3gV013596; Wed, 18 Aug 2004 22:17:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J5H2Dv013583; Wed, 18 Aug 2004 22:17:03 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 4F58A727D; Wed, 18 Aug 2004 22:17:10 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0535A419-F19F-11D8-9BC6-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: ID wording Date: Wed, 18 Aug 2004 22:17:09 -0700 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 18, 2004, at 1:57 PM, Paul Hoffman / IMC wrote: > Greetings again. Thanks for keeping the moratorium on ID discussion. I > thought it would be best to do a sanity check to be sure people were > in agreement on what it seems the consensus so far was. > > - The format for IDs is going to be URIs, not plain strings. > > - IDs must not change over time. > > - Even though the format is a URI, the IDs are not expected to be > dereferencable (although they might be). > > - IDs MUST be compared character-by-character, no case-mapping, no %xx > conversion, and so on. > > - Receiving and gateway systems MUST NOT alter IDs in any way. > > - Because IDs might be dereferenced, and because they must not be > changed, it is a good idea to create them in a canonicalized form. > There is no interoperability issues with this suggestion, so it is > just a suggestion, not a SHOULD-level suggestion. +1 - well said. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Aug 19 02:30:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04981 for ; Thu, 19 Aug 2004 02:30:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J6HmJA024082; Wed, 18 Aug 2004 23:17:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J6HmPx024081; Wed, 18 Aug 2004 23:17:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J6HlAv024059; Wed, 18 Aug 2004 23:17:47 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7J6Hril019347; Thu, 19 Aug 2004 00:17:53 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2O002WPK5SI1@edgemail1.Central.Sun.COM>; Thu, 19 Aug 2004 00:17:53 -0600 (MDT) Received: from [192.168.1.100] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2O003YBK5SL2@mail.sun.net>; Thu, 19 Aug 2004 00:17:52 -0600 (MDT) Date: Wed, 18 Aug 2004 23:18:02 -0700 From: Tim Bray Subject: Re: ID wording In-reply-to: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> To: Graham Cc: Paul Hoffman / IMC , Atom WG Message-id: <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 18, 2004, at 9:56 PM, Graham wrote: > (I still don't understand the case for canonicalized ids - is there > some reason for it beyond gateways that accidentally canonicalize not > doing any damage?) java.net.URI and the C# equivalent... a programmer sees that an atom:id is a URI and uses such things to store them, and well, they try to be smart. Yes, the programmer probably shouldn't do that. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 19 03:03:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06982 for ; Thu, 19 Aug 2004 03:03:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J6nkvn029759; Wed, 18 Aug 2004 23:49:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J6nkje029758; Wed, 18 Aug 2004 23:49:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J6njBR029737; Wed, 18 Aug 2004 23:49:45 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 86817727D; Wed, 18 Aug 2004 23:49:45 -0700 (PDT) In-Reply-To: <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Graham , Paul Hoffman / IMC , Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: ID wording Date: Wed, 18 Aug 2004 23:49:44 -0700 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ah. Can we agree to add this to the list; - If/when Atom is described with XML Schema, the ID should be a xs:string, not xs:anyURI. I.e., the content will be restricted to a URI in prose, not in the schema. ? On Aug 18, 2004, at 11:18 PM, Tim Bray wrote: > > On Aug 18, 2004, at 9:56 PM, Graham wrote: > >> (I still don't understand the case for canonicalized ids - is there >> some reason for it beyond gateways that accidentally canonicalize not >> doing any damage?) > > java.net.URI and the C# equivalent... a programmer sees that an > atom:id is a URI and uses such things to store them, and well, they > try to be smart. Yes, the programmer probably shouldn't do that. -Tim > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Aug 19 03:18:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07834 for ; Thu, 19 Aug 2004 03:18:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J6sMG7030874; Wed, 18 Aug 2004 23:54:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J6sMCk030871; Wed, 18 Aug 2004 23:54:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J6sLu5030837; Wed, 18 Aug 2004 23:54:21 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7J6sLil001339; Thu, 19 Aug 2004 00:54:21 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2O003M6LUKQU@edgemail1.Central.Sun.COM>; Thu, 19 Aug 2004 00:54:21 -0600 (MDT) Received: from [192.168.1.100] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2O00C21LUJE1@mail.sun.net>; Thu, 19 Aug 2004 00:54:20 -0600 (MDT) Date: Wed, 18 Aug 2004 23:54:29 -0700 From: Tim Bray Subject: Re: ID wording In-reply-to: To: Mark Nottingham Cc: Graham , Paul Hoffman / IMC , Atom WG Message-id: <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 18, 2004, at 11:49 PM, Mark Nottingham wrote: > Ah. Can we agree to add this to the list; > > - If/when Atom is described with XML Schema, the ID should be a > xs:string, not xs:anyURI. I.e., the content will be restricted to a > URI in prose, not in the schema. I'm nervous about getting that specific... this feels like it belongs in an Implementor's Guide or some such. I think we have agreement that we should provide schemas to help out (although not that they be normative), and a well-commented entry in such a schema seems like a good way to do it. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 19 04:40:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12993 for ; Thu, 19 Aug 2004 04:40:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J8Li2Q048926; Thu, 19 Aug 2004 01:21:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J8LiQY048925; Thu, 19 Aug 2004 01:21:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ims2.edisontel.com (mail2.edisontel.com [62.94.0.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J8LcWV048874; Thu, 19 Aug 2004 01:21:43 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from virgilio.it (62.94.5.213) by ims2.edisontel.com (6.7.019) id 3FCC577E0023DA68; Thu, 19 Aug 2004 10:16:30 +0200 Message-ID: <41246104.8080107@virgilio.it> Date: Thu, 19 Aug 2004 10:12:52 +0200 From: Danny Ayers Reply-To: danny.ayers@gmail.com User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org Subject: Re: Extensibility in Syndication formats References: <20040818153540.33046.qmail@web41203.mail.yahoo.com> In-Reply-To: <20040818153540.33046.qmail@web41203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In the same way that XML plus namespaces can keep terms separate at a syntax level without prior agreement between developers, the RDF model can keep terms separate at a logical level. Both are necessary to avoid interrnal conflict in applications. Without a similar mechanism (it could be considerably simpler) Atom will have to be very limited in terms of extensibility, or it won't scale. Dare Obasanjo wrote: >Before continuing, I'd like to note that besides >[perhaps] NewsMonster of the dozens of RSS aggregators >I have seen in action none treat extensibility in RSS >1.0 any different from extensibility in RSS 2.0. It's >all just XML and namespaces to them. The other >aggregator authors on the list can pipe up and >disagree with me if I am mistaken. > >Thus the claims of superiority of using RDF-based >extensibility in RSS 1.0 versus using XML + namespaces >as RSS 2.0 does have simply never been shown in the >wild besides the proof of concept stuff that the RDF >syndication usual suspects like Danny Ayers trot out >whenevr this discussion occurs. > > It's true that most popular aggregators don't support a wide range of extensions, but that is about implementation, not language design. As to their existence in the wild, the are *lots* of RDF stores around, all of which can consume RSS 1.0 based syndicated material. RSS aggregators are generally, by design, single-purpose applications for reading news-like feeds. Just for the record, here are a couple of RDF-based systems that had specific support for RSS material (there are more, I just don't have a list at hand): Intellidimension's Desktop Portal http://www.intellidimension.com/pages/site/packages/pportal/default.rsp (the same kit, RDF Gateway, is used in their search engine: http://www.semanticwebsearch.com/) Knobot: http://sourceforge.net/projects/knobot/ >So far all you've done is assert that RDF based >extensibility is better without showing why in >concrete terms. I don't see why you claim it is so >hard to reuse an element from one schema in another, >it hapopens all the time in the world of RSS. > Do you remember the fun surrounding the inclusion of xhtml:body in RSS 2.0 feeds? >Heck, >just a few days ago on this list we were discussing >using the dcterms:* elements in Atom without resorting >to using RDF-based extensibility, just XML and >namespaces. > > I don't think anyone's expecting Atom to use RDF-based extensibility, merely stating that RDF/XML approach has considerable advantages over XML plus namespaces alone. I would hope Atom will be able to support dcterms, but this will be fragile unless there is some kind of mandated use of these specific terms, or a more general purpose extensibility that allows namespace mixing in a general fashion. > >When feeds are carrying rich namespace-extended >descriptions of the things >the feeds describe (jobs, journals, products, >holidays, pornography, people, >cities, mail messages, CVS servers, journal >articles, paper-published >books, MP3s, Ogg streams, playlists, concert >listings, weather reports, security >alerts, blog comments, answerphone messages, bank >transactions, network >outages, TV schedules, dentist appointments, >football results, product >recalls, train times, blind dates, press releases >and -yesyes- blog posts, >... *then* we'll have 'atom everywhere'. But unless >we're going to slip >back 5 years in terms of expressivity, Atom needs a >way to allow all >these kinds of thing to be described using whatever >externally-managed >namespaces make sense in the marketplace. > > > >RSS 2.0 does all these and more today. It seems you >are either ignorant of what's happening in the >syndication space today or willfully ignoring the >current state of the syndication marketplace. > > No it doesn't. >It just seems you are advocating that vocabulary >designers not reinvent the wheel and reuse other >markup vocabularies where possible. Makes sense to me. > > For sure, but to be able to reuse those vocabularies it is necessary to consider how they may interact. >Sure. I still await concrete, technical reasons >preferably with scenario-driven use cases or examples >that show how using RDF based extensibility somehow >buys one significantly more than using XML based >extensibility on a global, decentralized network like >the World Wide Web. > > The concrete technical reason is that RDF-based extensibility ring-fences the terms through the data model expressed through RDF/XML syntax. There is nothing to define how individual XML-only terms work with core syndication terms, let alone each other. Unless you get every designer to agree with every other designer on specific interactions. I pasted this to the top as summation: In the same way that XML plus namespaces can keep terms separate at a syntax level without prior agreement between developers, the RDF model can keep terms separate at a logical level. Both are necessary to avoid interrnal conflict in applications. Without a similar mechanism (it could be considerably simpler) Atom will have to be very limited in terms of extensibility, or it won't scale. Cheers, Danny. > > -- Raw http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Aug 19 05:21:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14961 for ; Thu, 19 Aug 2004 05:21:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J95IE5065078; Thu, 19 Aug 2004 02:05:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J95ICl065077; Thu, 19 Aug 2004 02:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ims2.edisontel.com (mail2.edisontel.com [62.94.0.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J95HVw065054; Thu, 19 Aug 2004 02:05:18 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from virgilio.it (62.94.5.213) by ims2.edisontel.com (6.7.019) id 3FCC577E0023DB9D; Thu, 19 Aug 2004 11:00:13 +0200 Message-ID: <41246B44.8010303@virgilio.it> Date: Thu, 19 Aug 2004 10:56:36 +0200 From: Danny Ayers Reply-To: danny.ayers@gmail.com User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Ian Davis , Dan Brickley , Paul Hoffman / IMC , James Robertson , atom-syntax@imc.org Subject: Striping Atom (was Re: Extensibility in Syndication formats) References: <20040818204255.73722.qmail@web41209.mail.yahoo.com> In-Reply-To: <20040818204255.73722.qmail@web41209.mail.yahoo.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: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: >For example, a DOM based >implementation wouldn't have these issues you claim. >And in fact, all versions of RSS Bandit have used a >DOM for parsing XML and I recently changed this just a >few weeks but haven't shipped this change in a release >yet. > > Ok, so you're acknowledging the use of a model can be helpful in managing extensions. The DOM model provides a hierachical data model, whereas the RDF model can be seen in terms of a graph or a set of statements (triples). Perhaps somewhere between the two lies something useable in Atom. Why not just simple striping: Nested as much as needed, but always following the entity-relationship-entity-relationship-entity pattern. This would considerably disambiguate terms at the logical level, without introducing any of the kind of syntactic variation possible in RDF/XML. (entityB may alternately be a text node) e.g. The Title Ok, we know that one, but: Something States that entry has a characteristic called x:qwe with the value "Something". The current Atom syntax is very close to this already, the only exceptions I think being author/contributor which munges the entity with the relationship. Cheers, Danny. > > -- Raw http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Aug 19 05:42:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16122 for ; Thu, 19 Aug 2004 05:42:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J9Ejc9069190; Thu, 19 Aug 2004 02:14:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J9EjSI069188; Thu, 19 Aug 2004 02:14:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J9Eifc069075; Thu, 19 Aug 2004 02:14:44 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id A275F7C22E; Thu, 19 Aug 2004 12:06:29 +0200 (CEST) To: "Paul Hoffman / IMC" Cc: Atom-Syntax Subject: Re: ID wording References: Message-ID: Date: Thu, 19 Aug 2004 11:16:14 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 18 Aug 2004 13:57:48 -0700, Paul Hoffman / IMC wrote: > Does this match what people feel was the general consensus? Yes, very much so. But I'm not sure if any of your bullets include that the ID must be absolute, and not relative? If that is the canonicalization-part, then I feel this should be mentioned explicitly and be a MUST, not SHOULD. Absolute versus relative URI's as ID's is indeed a (big) interoperability issue. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 05:55:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16616 for ; Thu, 19 Aug 2004 05:55:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J9d8fq076853; Thu, 19 Aug 2004 02:39:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J9d8Ux076852; Thu, 19 Aug 2004 02:39:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7J9d65R076779 for ; Thu, 19 Aug 2004 02:39:07 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 14640 invoked by uid 65534); 19 Aug 2004 09:38:55 -0000 Received: from p508245DF.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.69.223) by mail.gmx.net (mp017) with SMTP; 19 Aug 2004 11:38:55 +0200 X-Authenticated: #1915285 Message-ID: <4124752E.4000800@gmx.de> Date: Thu, 19 Aug 2004 11:38:54 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Paul Hoffman / IMC , Atom-Syntax Subject: Re: ID wording References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Wed, 18 Aug 2004 13:57:48 -0700, Paul Hoffman / IMC > wrote: > >> Does this match what people feel was the general consensus? > > > Yes, very much so. But I'm not sure if any of your bullets include that > the ID must be absolute, and not relative? If that is the > canonicalization-part, then I feel this should be mentioned explicitly > and be a MUST, not SHOULD. Absolute versus relative URI's as ID's is > indeed a (big) interoperability issue. URIs always are absolute. Relative URIs are not URIs (duh!). See current discussion on http-uri mailing list. :-) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 19 06:10:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17229 for ; Thu, 19 Aug 2004 06:10:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J9xdTc084843; Thu, 19 Aug 2004 02:59:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J9xdEA084842; Thu, 19 Aug 2004 02:59:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J9xcj0084781 for ; Thu, 19 Aug 2004 02:59:38 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 10936 invoked from network); 19 Aug 2004 09:59:24 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 19 Aug 2004 09:59:24 -0000 Received: from 194.203.191.188 ([194.203.191.188]) by webmail.djpowell.net (IMP) with HTTP for ; Thu, 19 Aug 2004 10:59:24 +0100 Message-ID: <1092909564.412479fc13f94@webmail.djpowell.net> Date: Thu, 19 Aug 2004 10:59:24 +0100 From: David Powell To: Julian Reschke Cc: =?iso-8859-1?b?QXNiavhybg==?= Ulsberg , Paul Hoffman / IMC , Atom-Syntax Subject: Re: ID wording References: <4124752E.4000800@gmx.de> In-Reply-To: <4124752E.4000800@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 194.203.191.188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Julian Reschke : > > Asbjørn Ulsberg wrote: > > > > > On Wed, 18 Aug 2004 13:57:48 -0700, Paul Hoffman / IMC > > wrote: > > > >> Does this match what people feel was the general consensus? > > > > > > Yes, very much so. But I'm not sure if any of your bullets include that > > the ID must be absolute, and not relative? If that is the > > canonicalization-part, then I feel this should be mentioned explicitly > > and be a MUST, not SHOULD. Absolute versus relative URI's as ID's is > > indeed a (big) interoperability issue. > > URIs always are absolute. Relative URIs are not URIs (duh!). See current > discussion on http-uri mailing list. > > :-) > The other difference between a URI and a URI reference is that according to RFC2396classic the "absoluteUri" term doesn't allow fragments to be used, in RFC2396bis the "URI" term is introduced which does allow fragments. I think that fragments should definitely be allowed in atom:id - they are used widely in RDF, and if RDFers have already assigned URIRefs to their publications, they aren't going to be pleased about having to assign another set of id aliases for the benefit of Atom. Check out PaceUriReferences where I proposed replacing the use of "URI" with "URI Reference", and also proposed that atom:id should be an "absolute URI Reference". -- Dave From owner-atom-syntax@mail.imc.org Thu Aug 19 06:37:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19111 for ; Thu, 19 Aug 2004 06:37:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JAJCCZ091106; Thu, 19 Aug 2004 03:19:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JAJCif091105; Thu, 19 Aug 2004 03:19:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JAJ9ZY091077 for ; Thu, 19 Aug 2004 03:19:10 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id BF8437C1EE; Thu, 19 Aug 2004 13:11:01 +0200 (CEST) To: "Julian Reschke" Cc: Atom-Syntax Subject: Re: ID wording References: <4124752E.4000800@gmx.de> Message-ID: Date: Thu, 19 Aug 2004 12:21:01 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <4124752E.4000800@gmx.de> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 11:38:54 +0200, Julian Reschke wrote: > URIs always are absolute. Relative URIs are not URIs (duh!). Hmkay. Is it not necessary to write something about this in the specification, or do you think everyone that knows what an URI is also knows that it can't be relative? I remember a lengthy discussion about this on this list a while ago, and it took a long time for people to agree that atom:id should not be relative (even though most people thought it should be an URI). -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 07:06:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21031 for ; Thu, 19 Aug 2004 07:06:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JAtbEd004626; Thu, 19 Aug 2004 03:55:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JAtbAd004625; Thu, 19 Aug 2004 03:55:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JAtZXI004574 for ; Thu, 19 Aug 2004 03:55:36 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 40049 messnum 7772030 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 19 Aug 2004 10:55:32 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail01.svc.cra.dublin.eircom.net (qp 40049) with SMTP; 19 Aug 2004 10:55:32 -0000 Message-ID: <41248721.1070500@dehora.net> Date: Thu, 19 Aug 2004 11:55:29 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom WG Subject: Re: ID wording References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> In-Reply-To: <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > > On Aug 18, 2004, at 11:49 PM, Mark Nottingham wrote: > >> Ah. Can we agree to add this to the list; >> >> - If/when Atom is described with XML Schema, the ID should be a >> xs:string, not xs:anyURI. I.e., the content will be restricted to a >> URI in prose, not in the schema. > > > I'm nervous about getting that specific... this feels like it belongs in > an Implementor's Guide or some such. Sure it's specific, but's a real point of breakage. Also it only covers bindings off schema and not hand coded stuff (I'd be tempted to include some weasel words about using string types in programming languages). Ok, how about either, "XML Schema descriptions of Atom SHOULD prefer xsi:string to represent IDs. " or, we just agree to remember that schema coming off this WG will xsi:string. +1 to Paul's summary; good stuff. cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 19 07:38:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23192 for ; Thu, 19 Aug 2004 07:38:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBLgZA016046; Thu, 19 Aug 2004 04:21:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JBLg11016045; Thu, 19 Aug 2004 04:21:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBLfb9015987 for ; Thu, 19 Aug 2004 04:21:42 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 956A77C1EE; Thu, 19 Aug 2004 14:13:33 +0200 (CEST) Date: Thu, 19 Aug 2004 13:23:46 +0200 To: "David Powell" Subject: Re: Using DC only for informational dates (was: Re: Date paces) Cc: Atom-Syntax References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> <1092397529.411ca9d96959e@webmail.djpowell.net> <1021337343.20040815024400@djpowell.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <1021337343.20040815024400@djpowell.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sun, 15 Aug 2004 02:44:00 +0100, David Powell wrote: > I see Atom as a protocol for the transfer of metadata between agents. > Some fields in atom:entry are part of the protocol, and some are part > of the metadata/data. (The boundaries are a bit blurred though because > all protocol fields are also metadata.) Okay, now I see what you mean. > For example I'd class atom:id as part of the protocol - it is likely > that Atom will specify behaviours of how the Atom protocol interacts > with this field. I agree. > I'd class atom:title to be part of the metadata. Atom has done its job > if this field gets passed intact from the publisher to the client. The > client of course can process this field in any way it chooses, but it > is done outside of the Atom specification. There is another layer, though, where an atom:entry isn't metadata about another resource, but the first-class resource itself. Then, atom:title would be data, not metadata. The same goes for the other elements in atom:entry otherwise classified as «metadata». > (Perhaps we should be clearer in general about what the boundaries of > Atom are, otherwise we are likely to over-specify user-agent behaviour > and make intermediaries and automated "Atom services" difficult to > implement within the specification.) Yes. > An example of this principle in action would be dcterms:available. > This field is used to describe when a document was/will be made > available, but I believe that this field (like all of dcterms) should > only be used as an informational field. Clients should not expect that > setting a dcterms:available element to be in the future should hide > that entry - if clients require future publishing then that would need > to be specified as an extension using it's own namespace. Yes, or just by using an internal model for it. What would be interesting about 'available' as a part of Atom, is the date that ends the range, e.g. the date that tells when the entry is going away. This is still just informational, but it's nice to know. > (If I added to > my website I wouldn't expect it to disappear). Heh. :) > "Display date" is a bad name - I don't consider that date to be > "only-for-display". Yes, I agree. That's why I think the user-provided date should just be called «date», since it means different things to different people. What clients do with elements in Atom isn't that interesting, imho. As long as they remain clients (e.g. don't re-publish the data anywhere), they can do whatever they want with atom:date as well as atom:id. > I'd probably want to sort on it. ...Or on whatever other available element in the entry. Why should we refuse someone to sort entries on atom:title, or even atom:content? > In fact people might sort on absolutely any field. I think sort-order > is out of scope of the spec. I totally agree. I think going too far to specify what clients should do, if they indeed only are clients, is meaningless. We don't know what clients might want to do. Finding new uses for Atom is one of the virtues of such a new format, and we shouldn't restrict client behavior in the specification. Publisher's behaviour, however, should be restricted and specifically defined as much as possible. The current practice where 'pubDate' can represent any date, be immutable and whatever, is a practice we should discourage. Sure, provide an element they can push this ambiguous data into, but provide elements that have a bit more specific semantic value and meaning as well. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 07:41:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23323 for ; Thu, 19 Aug 2004 07:41:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBO47L016956; Thu, 19 Aug 2004 04:24:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JBO4XY016955; Thu, 19 Aug 2004 04:24:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JBO3Q1016910 for ; Thu, 19 Aug 2004 04:24:04 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 86049 messnum 370370 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 19 Aug 2004 11:23:59 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail05.svc.cra.dublin.eircom.net (qp 86049) with SMTP; 19 Aug 2004 11:23:59 -0000 Message-ID: <41248DCD.2030705@dehora.net> Date: Thu, 19 Aug 2004 12:23:57 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom WG Subject: Re: ID wording References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> <41248721.1070500@dehora.net> In-Reply-To: <41248721.1070500@dehora.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I forgot: > Ok, how about either, > > "XML Schema descriptions of Atom SHOULD prefer xsi:string to represent > IDs. " That's for assholes. > or, we just agree to remember that schema coming off this WG will > xsi:string. That's for morons. If we do both, we're covered, right? cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 19 07:45:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23615 for ; Thu, 19 Aug 2004 07:45:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBW746020285; Thu, 19 Aug 2004 04:32:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JBW7Io020284; Thu, 19 Aug 2004 04:32:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBW7M2020248 for ; Thu, 19 Aug 2004 04:32:07 -0700 (PDT) (envelope-from B.Lund@nature.com) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 8214420C170 for ; Thu, 19 Aug 2004 12:32:03 +0100 (BST) Received: from UK1APPS2.nature.com (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Thu, 19 Aug 2004 12:32:03 +0100 Received: by UK1APPS2.nature.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Aug 2004 12:32:03 +0100 Message-ID: <125F7834E11A5741A7D79412EE3504F90B17ECDE@UK1APPS2.nature.com> From: "Lund, Ben" To: "'atom-syntax@imc.org'" Subject: Re: Extensibility in Syndication formats Date: Thu, 19 Aug 2004 12:32:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi All, Some comments on various points raised in this thread: On 18/08/2004 16:35, Dare Obasanjo wrote: > Before continuing, I'd like to note that besides > [perhaps] NewsMonster of the dozens of RSS aggregators > I have seen in action none treat extensibility in RSS > 1.0 any different from extensibility in RSS 2.0. It's > all just XML and namespaces to them. The other > aggregator authors on the list can pipe up and > disagree with me if I am mistaken. Internally Urchin (http://urchin.sourceforge.net) treats data as RDF. The database schema has tables for storing the RSS-ish data, and a triple store for everything else. This allows it to capture, query on, and fully reconstitute all the data that's imported, without the application having to understand what it means. (A version that converts Atom to RDF for will be checked in to CVS in the next day or so.) On Wed, 18 Aug 2004 03:47:24 -0400, Dan Brickley wrote: > I'd be interested to take this > http://www.nature.com/naturejobs/jobs/biologicalsciences.rdf feed as a > test for AtomPub's extensibility goals. I'd also be very interested to see this rendered in Atom. When I set up this feed, modeling the jobs data as RDF seemed like the only sensible way of conveying the information accurately. For example, it is jobs, not job adverts that have locations, and the nj:advertises -> nj:Job -> nj:city RDF construct makes this nicely explicit. > Perhaps in the future, > scientifically minded job hunters will be able to go do a search on jobs > in their particular speciality and see the results using > geographically-oriented tools. And when we offer feeds of scientific conferences and events, see them displayed geographically too... It's exactly this cross-over application we had in mind when choosing the RDF model for this data. Sam Ruby [2004-08-18 07:52-0400]: > there are other serialization syntaxes than RDF/XML. I turns out that the RDF/XML syntax didn't cause us any implementation headaches at all. Ta, Ben --- ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ******************************************************************************** From owner-atom-syntax@mail.imc.org Thu Aug 19 07:49:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23937 for ; Thu, 19 Aug 2004 07:49:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBUP0D019513; Thu, 19 Aug 2004 04:30:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JBUPRY019512; Thu, 19 Aug 2004 04:30:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode01.zonnet.nl (postbode01.zonnet.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBUOTF019456 for ; Thu, 19 Aug 2004 04:30:25 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 22319 invoked by uid 10); 19 Aug 2004 11:30:20 -0000 Received: (vexira-qq 22303-4E5B73A invoked from network) 19 Aug 2004 13:30:20 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode01.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 19 Aug 2004 11:30:20 -0000 Message-ID: <41248F4F.5040504@annevankesteren.nl> Date: Thu, 19 Aug 2004 13:30:23 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom WG Subject: Re: ID wording References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> <41248721.1070500@dehora.net> <41248DCD.2030705@dehora.net> In-Reply-To: <41248DCD.2030705@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.20; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I forgot: > >> Ok, how about either, >> >> "XML Schema descriptions of Atom SHOULD prefer xsi:string to represent >> IDs. " > That's for assholes. > >> or, we just agree to remember that schema coming off this WG will >> xsi:string. > > That's for morons. > > If we do both, we're covered, right? We might need something for flamers[1]? I don't really understand why it should be a xsi:string, since it really is a URI, not? [1] -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Aug 19 07:52:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24040 for ; Thu, 19 Aug 2004 07:52:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBfVhN024236; Thu, 19 Aug 2004 04:41:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JBfVlJ024235; Thu, 19 Aug 2004 04:41:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBfUw4024182 for ; Thu, 19 Aug 2004 04:41:30 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 360C87C1EE; Thu, 19 Aug 2004 14:33:22 +0200 (CEST) To: "Bill Kearney" Cc: Atom-Syntax Subject: Re: dc:dates in atom - some questions References: <6563D963-ECC7-11D8-A471-003065EA6144@geckotribe.com> <09ee01c482da$8e068590$200ca8c0@wkearney.com> Message-ID: Date: Thu, 19 Aug 2004 13:43:40 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <09ee01c482da$8e068590$200ca8c0@wkearney.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sun, 15 Aug 2004 11:14:26 -0400, Bill Kearney wrote: >> That would imho be the recommended practice nonetheless. Future dates >> just doesn't make much sense, especially if what the publisher wants >> is the entry not to appear until the specified date and time arrives. > > Or use a format better suited for it. At the present time NewML, with > all of its syntactic complexities, is probably a better choice. Yes, probably. NewsML is, however, extremely complex. Atom is simple. > If and it's a BIG IF, the market evolves such that considerable consumer > demand exists for such things there's always room for further evolution > of the standard(s) involved. Indeed. I think, however, that for now, future dates should be discouraged. It's the publisher's, not the consumer's job, to hide the entry from the readers until the date and time it's supposed to be visible, arrives. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 07:55:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24203 for ; Thu, 19 Aug 2004 07:55:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JBkIg5026521; Thu, 19 Aug 2004 04:46:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JBkI42026520; Thu, 19 Aug 2004 04:46:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JBkHKa026476 for ; Thu, 19 Aug 2004 04:46:18 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 95854 messnum 376812 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 19 Aug 2004 11:45:03 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail05.svc.cra.dublin.eircom.net (qp 95854) with SMTP; 19 Aug 2004 11:45:03 -0000 Message-ID: <412492BC.7040204@dehora.net> Date: Thu, 19 Aug 2004 12:45:00 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom WG Subject: Re: ID wording References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> <41248721.1070500@dehora.net> <41248DCD.2030705@dehora.net> <41248F4F.5040504@annevankesteren.nl> In-Reply-To: <41248F4F.5040504@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > We might need something for flamers[1]? Nah... that's just Tim not stamping out creativity. [1] > I don't really understand why it should be a xsi:string, since it really > is a URI, not? It is, but we can't expect to get consistent equivalence calls across languages by the looks of things; strcmp seems to be the way to go for most implementors. I think Mark is thinking about cases where anyURI will be auto-marshalled onto a URI object rather than a String. cheers Bill [1] http://www.tbray.org/ongoing/When/200x/2003/06/27/NoInventions From owner-atom-syntax@mail.imc.org Thu Aug 19 08:20:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25994 for ; Thu, 19 Aug 2004 08:20:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JC4sv5034578; Thu, 19 Aug 2004 05:04:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JC4sgV034577; Thu, 19 Aug 2004 05:04:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JC4r35034547 for ; Thu, 19 Aug 2004 05:04:54 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id BD07C7C1EE; Thu, 19 Aug 2004 14:56:45 +0200 (CEST) Date: Thu, 19 Aug 2004 14:07:08 +0200 To: "Anne van Kesteren" Subject: Re: ID wording Cc: Atom-Syntax References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> <41248721.1070500@dehora.net> <41248DCD.2030705@dehora.net> <41248F4F.5040504@annevankesteren.nl> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <41248F4F.5040504@annevankesteren.nl> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 13:30:23 +0200, Anne van Kesteren wrote: > I don't really understand why it should be a xsi:string, since it really > is a URI, not? The problem with having it an URI in programming languages, is that they normalize and do a lot of other smart things with the URI string. That makes the «byte by byte» comparison useless, since whenever you've loaded a URI into e.g. the System.Uri type in .NET, it is potentially not the same as the original string anymore. It's somewhat the same as with dates. If we used dates for comparison, '2004-01-01T01:00:00+01:00' would be the same date as '2003-12-31T23:00:00-01:00', but they would not be the same string, compared byte by byte. (Not sure if this was a good example, but whatever :) -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 09:31:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01396 for ; Thu, 19 Aug 2004 09:31:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JD9eCC061146; Thu, 19 Aug 2004 06:09:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JD9en4061144; Thu, 19 Aug 2004 06:09:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JD9dbe061134 for ; Thu, 19 Aug 2004 06:09:39 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so2000rnb for ; Thu, 19 Aug 2004 06:09:38 -0700 (PDT) Received: by 10.38.8.67 with SMTP id 67mr2207049rnh; Thu, 19 Aug 2004 06:09:38 -0700 (PDT) Received: by 10.38.179.62 with HTTP; Thu, 19 Aug 2004 06:09:38 -0700 (PDT) Message-ID: <1f2ed5cd04081906097c25c0a@mail.gmail.com> Date: Thu, 19 Aug 2004 15:09:38 +0200 From: Danny Ayers Reply-To: Danny Ayers To: bob@wyman.us Subject: Re: It's about Reading -- not Writing... Cc: Atom-Syntax In-Reply-To: <200408181520.BNO36613@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408181520.BNO36613@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 18 Aug 2004 11:20:37 -0400, Bob Wyman wrote: > RDF may contribute, as Dan Brickley says, "a strategy for > decentralizing vocabulary design." However, the goal of the Atom effort is > to contribute a "strategy and means for communicating information." The > problems of designing vocabulary and of employing vocabulary (communicating) > are distinct. True, but one is dependent on the other. > The RDF camp seems enthralled by the glory of being able to easily > *express* a vast range of ideas with what is, at its core, a very simple set > of rules. However, we've learned over and over that RDF is more often > written then read. Non-RDF XML is the language of readers -- not RDF. The > reason is simple... RDF gives so much freedom to the writer that that reader > has little hope of understanding what is written. RDF is a versatile model in which information can be expressed, when passed from place to place communication can take place. But RDF/XML is more tightly constrained than XML in general. What one can understand > about something written in RDF is often no more meaningful then the examples > that Danny Ayers provides elsewhere. (e.g. Some unknown thing is said to > have a property which has unknown, but named, properties and that something > is said to have some undefined relationship to some other unknown thing... > How is this useful?) You can make comparisons between things without knowing everything about them. You can make simple inferences to fill in the gaps, making maximal use of whatever information is available. An approach such as RDF inference may not be any more useful in a particular situation than not using partial information, but discarding information can never more useful than extracting what you do understand. Do you know how you would get from your house to mine? Probably not, but you know how to figure it out from the available information. > If one is communicating in a small group it is reasonable to utilize > private vocabularies -- to produce "jargon" as it were. Small groups do this > constantly -- with our without RDF. But, if you wish to communicate to a > large group then, in order to *communicate*, you must express yourself with > a broadly understood and more rigorous language. I agree with the point in the context of machine languages, but it's a stretch to say English (for example) is rigorous. The opportunity for variety > and creativity in message construction is reduced as the size the audience > increases. > The key challenge of Atom is, I believe, to enable speaking to large > audiences. Thus, Atom should focus first on the problem of providing a well > and rigorously defined vocabulary that can be shared efficiently by a large > audience. Atom should be optimized for communications. I believe that this > means that Atom should rely on rigorously defined XML -- complete with > schemas, etc. I agree. The problem is that if extensions are required, then there needs to be some kind of commonality (rigour) beyond what XML+namespaces alone offers. > RDF is certainly a useful tool for "vocabulary design" and can be > very effective in small, closely-coupled groups -- thus, RDF can be useful > to those who are experimenting with and designing early vocabularies that > might later be formalized for broad use. In some small groups, the focus of > communications is so limited that such formalization may not ever be > justified or even necessary. This seems a strange way of looking at it - RDF can be just as useful for working on web scales too. Given this, I think Atom should provide a means > to encapsulate RDF within its XML -- to enable experimentation and > communication within fringe groups. > However, once a vocabulary has been "designed" as a result of small > group RDF use, it simply doesn't make sense to continue using RDF. Once the > vocabulary, or its core, has become fixed and well understood, the > flexibility of RDF becomes both a burden (because of bulk, parsing > difficulties, etc.) as well as unnecessary to communicate those things that > have been formalized. Thus, *formal* extensions to Atom, intended to be used > by the broad market, should be defined rigorously in as non-RDF XML. So you are in effect proposing one single, growing, megalanguage (with RDF as a kind of prototyping system). I'm not optimistic about that approach to scaling. > Insisting on XML as the format for broad audience communication does > nothing to limit the RDF people. As shown by GRDDL[1], you can convert > easily between XML and RDF. The RDF-folk can view the whole world as RDF if > they want... On the other hand, insisting on well and rigorously defined XML > for Atom will make it much more likely that the users of Atom will be able > to accomplish their communications goals -- because they will have agreed > upon common vocabularies with some sense that their audience, *the readers* > of Atom files, will understand. I don't really disagree, having core Atom as non-RDF XML isn't really much of an issue. > The Atom extensibility mechanisms should address at least two > concerns: > 1. Adding additional "standard" elements that are expected to be > understood by *all* or a large number of Atom readers. > 2. Providing the flexibility needed by vocabulary designers, small > groups, and others who require or desire non-standard vocabularies. > The mechanisms which are most appropriate to handle the first > concern are probably not the same as those which are most appropriate for > the second. Couldn't a scalable, modular mechanism cover both? > Please remember: It's about reading -- not writing... There has to be something to read, surely..? Cheers, Danny. From owner-atom-syntax@mail.imc.org Thu Aug 19 09:53:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02532 for ; Thu, 19 Aug 2004 09:53:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JDhEf3073627; Thu, 19 Aug 2004 06:43:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JDhENX073626; Thu, 19 Aug 2004 06:43:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JDhDac073614 for ; Thu, 19 Aug 2004 06:43:13 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7JDhFil008246 for ; Thu, 19 Aug 2004 07:43:15 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2P003764S3QU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 19 Aug 2004 07:43:15 -0600 (MDT) Received: from [192.168.1.100] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2P003FK4S2L2@mail.sun.net> for atom-syntax@imc.org; Thu, 19 Aug 2004 07:43:15 -0600 (MDT) Date: Thu, 19 Aug 2004 06:43:24 -0700 From: Tim Bray Subject: Re: ID wording In-reply-to: <41248721.1070500@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Atom WG Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> <41248721.1070500@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JDhDac073618 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Aug 19, 2004, at 3:55 AM, Bill de hÓra wrote: > Tim Bray wrote: >> On Aug 18, 2004, at 11:49 PM, Mark Nottingham wrote: >>> Ah. Can we agree to add this to the list; >>> >>> - If/when Atom is described with XML Schema, the ID should be a >>> xs:string, not xs:anyURI. I.e., the content will be restricted to a >>> URI in prose, not in the schema. >> I'm nervous about getting that specific... this feels like it belongs >> in an Implementor's Guide or some such. > > Sure it's specific, but's a real point of breakage. In my experience, RFCs which describe protocols rarely include discussion of the appropriate C or Java data types to hold things like IPv* addresses or DNS names. Now, you could argue that Atom is different from other protocols, or you could argue that schemas are different from programming language data types. But it still feels a little weird to find this kind of implementation recommendation in the protocol description. So... > or, we just agree to remember that schema coming off this WG will > xsi:string. I like that -Tim From owner-atom-syntax@mail.imc.org Thu Aug 19 10:28:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06047 for ; Thu, 19 Aug 2004 10:28:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JEFuGV086464; Thu, 19 Aug 2004 07:15:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JEFtMT086463; Thu, 19 Aug 2004 07:15:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41211.mail.yahoo.com (web41211.mail.yahoo.com [66.218.93.44]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JEFtZR086419 for ; Thu, 19 Aug 2004 07:15:55 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040819141552.39742.qmail@web41211.mail.yahoo.com> Received: from [24.18.136.49] by web41211.mail.yahoo.com via HTTP; Thu, 19 Aug 2004 07:15:52 PDT Date: Thu, 19 Aug 2004 07:15:52 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID wording To: "Asbjørn_Ulsberg" , Julian Reschke Cc: Atom-Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Asbjørn_Ulsberg wrote: > > On Thu, 19 Aug 2004 11:38:54 +0200, Julian Reschke > > wrote: > > > URIs always are absolute. Relative URIs are not > URIs (duh!). > > Hmkay. Is it not necessary to write something about > this in the > specification, or do you think everyone that knows > what an URI is also > knows that it can't be relative? I remember a > lengthy discussion about > this on this list a while ago, and it took a long > time for people to agree > that atom:id should not be relative (even though > most people thought it > should be an URI). Relative URIs not being URIs is a new stance that is showing up on discussions about this issue on other mailing lists. As far as I'm aware relative URIs have been considered URIs for as long as they have existed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Thu Aug 19 10:43:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07083 for ; Thu, 19 Aug 2004 10:43:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JESeu2092615; Thu, 19 Aug 2004 07:28:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JESexH092613; Thu, 19 Aug 2004 07:28:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JESeI5092556 for ; Thu, 19 Aug 2004 07:28:40 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040819142837.34119.qmail@web41205.mail.yahoo.com> Received: from [24.18.136.49] by web41205.mail.yahoo.com via HTTP; Thu, 19 Aug 2004 07:28:37 PDT Date: Thu, 19 Aug 2004 07:28:37 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID wording To: Paul Hoffman / IMC , Atom WG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Paul Hoffman / IMC wrote: > > Greetings again. Thanks for keeping the moratorium > on ID discussion. > I thought it would be best to do a sanity check to > be sure people > were in agreement on what it seems the consensus so > far was. > > - The format for IDs is going to be URIs, not plain > strings. > > - IDs must not change over time. > > - Even though the format is a URI, the IDs are not > expected to be > dereferencable (although they might be). > > - IDs MUST be compared character-by-character, no > case-mapping, no > %xx conversion, and so on. > > - Receiving and gateway systems MUST NOT alter IDs > in any way. > > - Because IDs might be dereferenced, and because > they must not be > changed, it is a good idea to create them in a > canonicalized form. > There is no interoperability issues with this > suggestion, so it is > just a suggestion, not a SHOULD-level suggestion. > > Does this match what people feel was the general > consensus? Yes, except for the stuff about IDs not being relative URIs being missing. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Thu Aug 19 11:34:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10379 for ; Thu, 19 Aug 2004 11:34:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFF7Va011630; Thu, 19 Aug 2004 08:15:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JFF7Hl011629; Thu, 19 Aug 2004 08:15:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFF669011622 for ; Thu, 19 Aug 2004 08:15:06 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7JFGwpG015584 for ; Thu, 19 Aug 2004 11:16:59 -0400 Message-ID: <4124C3FC.80000@intertwingly.net> Date: Thu, 19 Aug 2004 11:15:08 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> In-Reply-To: <20040819142837.34119.qmail@web41205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceIdConstruct During the id discussion moratorium, I worked on a Pace that attempted to capture Paul's rendition of consensus as spec text. It contains two notable additions: atom:id MUST NOT be a relative URI atom:head elements MUST contain an atom:id element The former seems to be the consensus of this mailing list. The latter simplifies the definition of atom:origin. Either could be split off into a separate pace. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 19 12:04:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12313 for ; Thu, 19 Aug 2004 12:04:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFrpGc018369; Thu, 19 Aug 2004 08:53:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JFrpvk018368; Thu, 19 Aug 2004 08:53:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFroCl018331 for ; Thu, 19 Aug 2004 08:53:51 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id IAA11668 for ; Thu, 19 Aug 2004 08:53:46 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id IAA17352 for ; Thu, 19 Aug 2004 08:53:46 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Thu, 19 Aug 2004 08:53:46 -0700 Received: from adsl-64-166-133-244.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7JFrilB021943 for ; Thu, 19 Aug 2004 08:53:45 -0700 (PDT) Date: Thu, 19 Aug 2004 08:53:44 -0700 From: Walter Underwood To: Atom WG Subject: Re: ID wording Message-ID: <12EF48074463D33C6E93E590@adsl-64-166-133-244.dsl.snfc21.pacbell.net> In-Reply-To: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Wednesday, August 18, 2004 11:56 PM -0500 Graham wrote: > > (I still don't understand the case for canonicalized ids - is there > some reason for it beyond gateways that accidentally canonicalize not > doing any damage?) 1) Consistency. it is good for other URIs in Atom to be canonical, so why are IDs different? Inconsistency makes implementation more error-prone. 2) Integration into multi-protocol systems. Atom will be used in systems with information pulled from RSS, web spidering, doucument databases, and those clients probably already canonicalize all URIs. Why is it correct for all other URIs and forbidden for these? Another source of error. It is hard enough merging data from HTML, MS Word, and PDF without odd rules like this. 3) It simplifies the test cases. The requirement for no-change copying requires inputs and outputs to test. A requirement for canonical URIs does not. Test the output for canonical form. 4) It seems really weird to me that we require URIs, then compare them like strings, then don't require the single step that makes that comparison reliable under transformations. It sets off some sort of design alarm in my head. Require apples and handle them like oranges. If Atom is successful, it will be implemented by lots of people who are not paying enough attention. Simple, consistent specs make the protocol more likely to work in the wild. I guess it is the robustness principle. To be conservative in what we generate, use canonical URIs. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu Aug 19 12:27:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14607 for ; Thu, 19 Aug 2004 12:27:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGDC7u021316; Thu, 19 Aug 2004 09:13:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JGDCYh021315; Thu, 19 Aug 2004 09:13:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGDBmJ021306 for ; Thu, 19 Aug 2004 09:13:12 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BxpXH-0001Qe-8R; Thu, 19 Aug 2004 16:13:07 +0000 Message-ID: <4124D18D.70200@franklinmint.fm> Date: Thu, 19 Aug 2004 12:13:01 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> In-Reply-To: <4124C3FC.80000@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > http://www.intertwingly.net/wiki/pie/PaceIdConstruct > "An Identification construct is an element whose content identifies the parent element of the construct. If nothing else is stated for a given Identification construct, the following rules apply:" It seems that Identification Constructs are intentionally being left open to extension, and the bulk of its semantics are optional. Why? Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 19 12:39:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15114 for ; Thu, 19 Aug 2004 12:39:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGNNr6022899; Thu, 19 Aug 2004 09:23:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JGNN6M022898; Thu, 19 Aug 2004 09:23:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode01.zonnet.nl (postbode01.zonnet.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGNL4f022879 for ; Thu, 19 Aug 2004 09:23:22 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 24297 invoked by uid 10); 19 Aug 2004 16:23:19 -0000 Received: (vexira-qq 24279-5FEA77D1 invoked from network) 19 Aug 2004 18:23:19 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode01.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 19 Aug 2004 16:23:19 -0000 Message-ID: <4124D3FA.1020406@annevankesteren.nl> Date: Thu, 19 Aug 2004 18:23:22 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: ID wording References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> <41248721.1070500@dehora.net> <41248DCD.2030705@dehora.net> <41248F4F.5040504@annevankesteren.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > The problem with having it an URI in programming languages, is that > they normalize and do a lot of other smart things with the URI string. > That makes the «byte by byte» comparison useless, since whenever you've > loaded a URI into e.g. the System.Uri type in .NET, it is potentially > not the same as the original string anymore. > > It's somewhat the same as with dates. If we used dates for comparison, > '2004-01-01T01:00:00+01:00' would be the same date as > '2003-12-31T23:00:00-01:00', but they would not be the same string, > compared byte by byte. (Not sure if this was a good example, but > whatever :) Yeah, I understand it. But isn't this a limitation of XML Schema? You would expect that you could somehow declare that it is a URI (it is and would look semantically more appropriate), but you may not normalize/resolve it. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Aug 19 12:40:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15185 for ; Thu, 19 Aug 2004 12:40:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGN14e022847; Thu, 19 Aug 2004 09:23:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JGN1XK022846; Thu, 19 Aug 2004 09:23:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGMuc2022819 for ; Thu, 19 Aug 2004 09:22:56 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7JGMx53011161 for ; Thu, 19 Aug 2004 10:22:59 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2P00FMAC6APK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 19 Aug 2004 10:22:59 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2P00LUDC69XL@mail.sun.net> for atom-syntax@imc.org; Thu, 19 Aug 2004 10:22:58 -0600 (MDT) Date: Thu, 19 Aug 2004 09:23:07 -0700 From: Tim Bray Subject: Re: PaceIdConstruct In-reply-to: <4124C3FC.80000@intertwingly.net> To: Atom WG Cc: Joe Gregorio , Robert Sayre , Mark Nottingham , Mark Pilgrim Message-id: <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 19, 2004, at 8:15 AM, Sam Ruby wrote: > http://www.intertwingly.net/wiki/pie/PaceIdConstruct > > During the id discussion moratorium, I worked on a Pace that attempted > to capture Paul's rendition of consensus as spec text. It contains > two notable additions: > > atom:id MUST NOT be a relative URI > atom:head elements MUST contain an atom:id element > > The former seems to be the consensus of this mailing list. The latter > simplifies the definition of atom:origin. Either could be split off > into a separate pace. My judgment, based on what I've seen in the list, is that everything here has good (not "rough") consensus except for the final item: "atom:head MUST contain atom:id". I agree about atom:origin, but as far as I can recall this is the first time this issue's really been brought to our attention. So, in the spirit of grabbing consensus while we can and moving on, I think our editors should grab the text (except for the atom:head/atom:id bit) and plow it into their working-copy drafts forthwith. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 19 12:53:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15976 for ; Thu, 19 Aug 2004 12:53:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGc4Ss026574; Thu, 19 Aug 2004 09:38:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JGc4ps026573; Thu, 19 Aug 2004 09:38:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGc35Q026566 for ; Thu, 19 Aug 2004 09:38:03 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7JGdsVO020589; Thu, 19 Aug 2004 12:39:54 -0400 Message-ID: <4124D76C.2030108@intertwingly.net> Date: Thu, 19 Aug 2004 12:38:04 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124D18D.70200@franklinmint.fm> In-Reply-To: <4124D18D.70200@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Sam Ruby wrote: > >> http://www.intertwingly.net/wiki/pie/PaceIdConstruct > > "An Identification construct is an element whose content identifies the > parent element of the construct. If nothing else is stated for a given > Identification construct, the following rules apply:" > > It seems that Identification Constructs are intentionally being left > open to extension, and the bulk of its semantics are optional. Why? That portion was lifted from PaceRecommendIdScheme. I see no reason to explicitly call out the possibility of extension. Care to suggest an alternate wording? I disagree that the "bulk of its semantics are optional". I see the key semantics as being: * It MUST be universally unique, which means that it must be unique both at the time of creation and in the future. * It MUST NOT change over time, even if the parent feed or entry element is relocated, migrated, syndicated, republished, exported or imported. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 19 13:16:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17448 for ; Thu, 19 Aug 2004 13:16:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JH5123030084; Thu, 19 Aug 2004 10:05:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JH51Lj030083; Thu, 19 Aug 2004 10:05:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JH4xBb030062 for ; Thu, 19 Aug 2004 10:05:00 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 18318 invoked from network); 19 Aug 2004 17:10:00 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 19 Aug 2004 17:10:00 -0000 Subject: Re: ID wording From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Atom WG In-Reply-To: <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> Content-Type: text/plain Message-Id: <1092935175.2544.4.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 19 Aug 2004 18:06:15 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-08-19 at 07:54, Tim Bray wrote: > I think we have agreement that > we should provide schemas to help out (although not that they be > normative), I don't recall any such agreement recently Tim? Was that some time ago? I'm -1 on that. If an atom instance can't be validated against a schema, I for one will lose any interest in using it. -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Thu Aug 19 13:16:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17466 for ; Thu, 19 Aug 2004 13:16:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JH2Vl4029689; Thu, 19 Aug 2004 10:02:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JH2VjZ029688; Thu, 19 Aug 2004 10:02:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JH2UNJ029663 for ; Thu, 19 Aug 2004 10:02:30 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040819170228.41368.qmail@web41215.mail.yahoo.com> Received: from [24.18.136.49] by web41215.mail.yahoo.com via HTTP; Thu, 19 Aug 2004 10:02:28 PDT Date: Thu, 19 Aug 2004 10:02:28 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID wording To: Anne van Kesteren , "Asbjørn_Ulsberg" Cc: Atom-Syntax In-Reply-To: <4124D3FA.1020406@annevankesteren.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Anne van Kesteren wrote: > > Yeah, I understand it. But isn't this a limitation > of XML Schema? You > would expect that you could somehow declare that it > is a URI (it is and > would look semantically more appropriate), but you > may not > normalize/resolve it. So there should be some way to declare a type as being a URI but specifying that it shouldn't be treated like URI? I'm not even sure what that means. Should there also be a means for claiming that something is an integer but specifying that you shouldn't use it for arithmetic operations? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Thu Aug 19 13:20:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17744 for ; Thu, 19 Aug 2004 13:20:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHBbOO030973; Thu, 19 Aug 2004 10:11:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JHBb4k030972; Thu, 19 Aug 2004 10:11:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHBbps030955 for ; Thu, 19 Aug 2004 10:11:37 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004081917113201600jvs55e>; Thu, 19 Aug 2004 17:11:32 +0000 Date: Thu, 19 Aug 2004 11:11:31 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceDateUpdated posted From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceDateUpdated Rationale * "Updated" is the most useful single date for enabling meaningful sort order. For those who wish to sort by "issued", they can get close enough by caching the first value they see in atom:updated, and sorting by the original value if atom:updated changes. Those who wish to sort by atom:updated can obviously do that too. * There are objections to duplicating dates from dcterms in the Atom core. dcterms does not have anything that matches atom:updated. Proposal Replace sections 5.6, 5.7 and 5.8 with the following: 5.6 "atom:updated" Element The "atom:updated" element is a Date Construct indicating the most recent date and time when a change was made to the entry which the publisher wishes to bring to the attention of subscribers. Such changes will typically not include minor adjustments like spelling and grammatical corrections. atom:entry elements MUST contain exactly one atom:date element. The content of this element MUST conform to the Date and Time format defined in [WWW]RFC 3339. Consumers MAY choose to sort based on this value. If the value of atom:updated for an atom:entry changes, consumers MAY choose to continue to sort based on the original value rather than the new value. If atom:updated specifies a future date, consumers MAY choose not to display entries until the date specified. From owner-atom-syntax@mail.imc.org Thu Aug 19 13:23:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17974 for ; Thu, 19 Aug 2004 13:23:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHDvd9031406; Thu, 19 Aug 2004 10:13:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JHDvEj031405; Thu, 19 Aug 2004 10:13:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHDuGp031366 for ; Thu, 19 Aug 2004 10:13:57 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc11) with SMTP id <20040819171354011004t6t9e>; Thu, 19 Aug 2004 17:13:54 +0000 Date: Thu, 19 Aug 2004 11:13:53 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceDateSubjective posted From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <258384BE-F203-11D8-B4D4-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Don't worry, the proposed name for the element is not "atom:subjective". http://www.intertwingly.net/wiki/pie/PaceDateSubjective Abstract Define an explicitly subjective Date Construct. Rationale * For some purposes, it is desirable to be able to specify a date connected to the content of an entry, rather than to an event in the process of publishing that content. * Some existing systems cannot provide an objective date. * There are objections to duplicating dates from dcterms in the Atom core. dcterms does not have anything that matches this element. Proposal Replace sections 5.6, 5.7 and 5.8 with the following: 5.6 "atom:date" Element The "atom:d" element is a Date Construct indicating a date and time which the publisher wishes to associate with the contents of the entry. It need not be related to events in the publishing process. For example, atom:d might be used to express the date which a journal entry describes, although that entry might have been written at a later date, or it may be used similarly to automobile model years or magazine edition months, both of which tend to be dated after they actually become available. atom:entry elements MAY contain an atom:date element but MUST NOT contain more than one. The content of this element MUST conform to the Date and Time format defined in [WWW]RFC 3339. From owner-atom-syntax@mail.imc.org Thu Aug 19 13:26:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18146 for ; Thu, 19 Aug 2004 13:26:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHFBmi031597; Thu, 19 Aug 2004 10:15:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JHFBD9031596; Thu, 19 Aug 2004 10:15:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHFBaN031590 for ; Thu, 19 Aug 2004 10:15:11 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BxqVM-0002qF-JQ; Thu, 19 Aug 2004 17:15:12 +0000 Message-ID: <4124E019.5010608@franklinmint.fm> Date: Thu, 19 Aug 2004 13:15:05 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124D18D.70200@franklinmint.fm> <4124D76C.2030108@intertwingly.net> In-Reply-To: <4124D76C.2030108@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > >> >> "An Identification construct is an element whose content identifies >> the parent element of the construct. If nothing else is stated for a >> given Identification construct, the following rules apply:" > > I see no reason to explicitly call out the possibility of extension. > Care to suggest an alternate wording? > An Identification construct is an element whose content identifies the parent element of the construct. Its content MUST be a URI, subject to the following rules: * It conveys a permanent, universally unique identifier for its parent element * It MUST be universally unique, which means that it must be unique both at the time of creation and in the future. * It MUST NOT change over time, even if the parent feed or entry element is relocated, migrated, syndicated, republished, exported or imported. * atom:id MUST NOT be a relative URI (see "absoluteURI" in RFC-[RFC]2369, section 3) > I disagree that the "bulk of its semantics are optional". I see the key > semantics as being... They are only optional in the presence of the qualifier "If nothing else is stated...", so my wording removes that. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 19 13:39:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18955 for ; Thu, 19 Aug 2004 13:39:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHHADC031886; Thu, 19 Aug 2004 10:17:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JHHAV0031885; Thu, 19 Aug 2004 10:17:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode03.zonnet.nl (postbode03.zonnet.nl [62.58.50.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHH9QQ031861 for ; Thu, 19 Aug 2004 10:17:09 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 27768 invoked by uid 10); 19 Aug 2004 17:17:05 -0000 Received: (vexira-qq 27751-1796052 invoked from network) 19 Aug 2004 19:17:04 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode03.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 19 Aug 2004 17:17:04 -0000 Message-ID: <4124E08F.2010100@annevankesteren.nl> Date: Thu, 19 Aug 2004 19:17:03 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Dare Obasanjo CC: =?ISO-8859-1?Q?Asbj=F8rn=5FUlsberg?= , Atom-Syntax Subject: Re: ID wording References: <20040819170228.41368.qmail@web41215.mail.yahoo.com> In-Reply-To: <20040819170228.41368.qmail@web41215.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> Yeah, I understand it. But isn't this a limitation of XML Schema? >> You would expect that you could somehow declare that it is a URI >> (it is and would look semantically more appropriate), but you may >> not normalize/resolve it. > > So there should be some way to declare a type as being a URI but > specifying that it shouldn't be treated like URI? I'm not even sure > what that means. Should there also be a means for claiming that > something is an integer but specifying that you shouldn't use it for > arithmetic operations? You explain my problems with xs:string. Thanks. If it can't be described with xs:anyURI, why does ID have to be an URI? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Aug 19 13:52:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19795 for ; Thu, 19 Aug 2004 13:52:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHUIh9034137; Thu, 19 Aug 2004 10:30:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JHUI28034136; Thu, 19 Aug 2004 10:30:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHUH1l034128 for ; Thu, 19 Aug 2004 10:30:18 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7JHWAxh023610; Thu, 19 Aug 2004 13:32:10 -0400 Message-ID: <4124E3AC.6010402@intertwingly.net> Date: Thu, 19 Aug 2004 13:30:20 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124D18D.70200@franklinmint.fm> <4124D76C.2030108@intertwingly.net> <4124E019.5010608@franklinmint.fm> In-Reply-To: <4124E019.5010608@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > Sam Ruby wrote: > >> I see no reason to explicitly call out the possibility of extension. >> Care to suggest an alternate wording? > > An Identification construct is an element whose content identifies the > parent element of the construct. Its content MUST be a URI, subject to > the following rules: > > * It conveys a permanent, universally unique identifier for its > parent element > * It MUST be universally unique, which means that it must be unique > both at the time of creation and in the future. > * It MUST NOT change over time, even if the parent feed or entry > element is relocated, migrated, syndicated, republished, exported or > imported. > * atom:id MUST NOT be a relative URI (see "absoluteURI" in > RFC-[RFC]2369, section 3) Thanks! Committed. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 19 13:58:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20123 for ; Thu, 19 Aug 2004 13:58:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHZR47034926; Thu, 19 Aug 2004 10:35:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JHZRMb034924; Thu, 19 Aug 2004 10:35:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JHZRFf034904 for ; Thu, 19 Aug 2004 10:35:27 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040819173522.48143.qmail@web41215.mail.yahoo.com> Received: from [24.18.136.49] by web41215.mail.yahoo.com via HTTP; Thu, 19 Aug 2004 10:35:22 PDT Date: Thu, 19 Aug 2004 10:35:22 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID wording To: Anne van Kesteren Cc: "Asbjørn_Ulsberg" , Atom-Syntax In-Reply-To: <4124E08F.2010100@annevankesteren.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Anne van Kesteren wrote: > > You explain my problems with xs:string. Thanks. If > it can't be described > with xs:anyURI, why does ID have to be an URI? IDs have to be globally unique. Many feel that URIs are a cheap way for people to come up with globally unique identifiers. The Web architecture is about using URIs as identifiers (see RDF & XML namespaces). ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 19 14:12:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20871 for ; Thu, 19 Aug 2004 14:12:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHottp037256; Thu, 19 Aug 2004 10:50:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JHotSv037255; Thu, 19 Aug 2004 10:50:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JHosZh037217 for ; Thu, 19 Aug 2004 10:50:54 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 1562 invoked by uid 17064); 19 Aug 2004 17:50:50 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.6.57]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 19 Aug 2004 17:50:50 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <4C1D2D5A-F208-11D8-BAC6-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom Syntax From: Henry Story Subject: extensibility: request for ideas Date: Thu, 19 Aug 2004 19:50:45 +0200 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "if atom can't do X, then i'm outta here" Anonymous Why not find out how Atom can do everything? What types of extensions to Atom would people like? What crazy things do people want to do? Why not make a big list of these? Then we can look at them one by one, or together, and see how the current format stacks up against an RDF format like the Atom-OWL format I recently presented [1]. I will be quite happy to try to mock up different example feeds, and perhaps others can participate too. The source code for the examples are available online, and writing an extension is not that difficult. This will help everyone get a little familiar with RDF, and get a better feel of what may or may not be needed. My bet is that this will allow us to do 2 things: 1) satisfy the huge urge to add more and more things to Atom 2) allow the spec to get out on time, because we won't have to deal with each of these issues Henry Story PS. I know we have allready mentioned a few, but I want this request to only be a question. I'll post some answers myself in return. [1] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html From owner-atom-syntax@mail.imc.org Thu Aug 19 14:23:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21899 for ; Thu, 19 Aug 2004 14:22:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIBFl0040060; Thu, 19 Aug 2004 11:11:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIBFfU040059; Thu, 19 Aug 2004 11:11:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIBErT040019 for ; Thu, 19 Aug 2004 11:11:15 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 465CA7C1F9; Thu, 19 Aug 2004 21:03:01 +0200 (CEST) To: "Sam Ruby" Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> Message-ID: Date: Thu, 19 Aug 2004 20:13:43 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <4124C3FC.80000@intertwingly.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 11:15:08 -0400, Sam Ruby wrote: > http://www.intertwingly.net/wiki/pie/PaceIdConstruct Ah, brilliant. +1. If there is lots of objections to the «MUST contain» wording in 4.2.6, I will have no problems with SHOULD. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 14:31:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22332 for ; Thu, 19 Aug 2004 14:31:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIELYh040470; Thu, 19 Aug 2004 11:14:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIELpN040469; Thu, 19 Aug 2004 11:14:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIEKW2040451 for ; Thu, 19 Aug 2004 11:14:20 -0700 (PDT) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with asmtp (Exim 4.41) id 1BxrQV-0001f5-7h; Thu, 19 Aug 2004 20:14:15 +0200 Received: from pd9fc534c.dip.t-dialin.net ([217.252.83.76]) by mx0.freenet.de with asmtp (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1BxrQU-0000Ag-O3; Thu, 19 Aug 2004 20:14:15 +0200 Message-ID: <4124EDCB.5020004@rbg.informatik.tu-darmstadt.de> Date: Thu, 19 Aug 2004 20:13:31 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Atom-Syntax Subject: Re: ID wording References: <20040819170228.41368.qmail@web41215.mail.yahoo.com> In-Reply-To: <20040819170228.41368.qmail@web41215.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > Anne van Kesteren wrote: >> Yeah, I understand it. But isn't this a limitation of XML Schema? >> You would expect that you could somehow declare that it is a URI >> (it is and would look semantically more appropriate), but you may >> not normalize/resolve it. Well, what should be possible is to declare that it is a string which has to _look_ like an URI. > So there should be some way to declare a type as being a URI but > specifying that it shouldn't be treated like URI? I'm not even sure > what that means. Should there also be a means for claiming that > something is an integer but specifying that you shouldn't use it for > arithmetic operations? So you might want to consider restricting xsd:string with the pattern facet, i.e. a probably long and ugly regex, such that the restricted type only allows strings respecting the URI syntax. And being a mere subtype of xsd:string it is quite clear that comparison has to be done character-by-character. Would this solve the problem? Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Thu Aug 19 14:34:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22610 for ; Thu, 19 Aug 2004 14:34:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIIHG3040994; Thu, 19 Aug 2004 11:18:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIIHjW040993; Thu, 19 Aug 2004 11:18:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode01.zonnet.nl (postbode01.zonnet.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIIG4V040983 for ; Thu, 19 Aug 2004 11:18:16 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 23656 invoked by uid 10); 19 Aug 2004 18:18:14 -0000 Received: (vexira-qq 23624-AB304F6B invoked from network) 19 Aug 2004 20:18:14 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode01.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 19 Aug 2004 18:18:14 -0000 Message-ID: <4124EEE2.6000703@annevankesteren.nl> Date: Thu, 19 Aug 2004 20:18:10 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Sam Ruby CC: Atom WG , =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> In-Reply-To: <4124C3FC.80000@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > http://www.intertwingly.net/wiki/pie/PaceIdConstruct From that page: # http://www.example.org/rosé That is not a valid URI. However, it is a valid IRI which will become a recommendation soon[1]. Is Atom going to do anything with IRIs? [1] -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Aug 19 14:36:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22700 for ; Thu, 19 Aug 2004 14:36:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIO24X041749; Thu, 19 Aug 2004 11:24:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIO2cW041748; Thu, 19 Aug 2004 11:24:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIO1Bx041731 for ; Thu, 19 Aug 2004 11:24:01 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 882817C1F9; Thu, 19 Aug 2004 21:15:52 +0200 (CEST) Date: Thu, 19 Aug 2004 20:25:33 +0200 To: "Tim Bray" Subject: Re: Next step on Dates Cc: Atom-Syntax References: <0E0F1F40-F163-11D8-99EE-000A95A51C9E@sun.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <0E0F1F40-F163-11D8-99EE-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 18 Aug 2004 15:07:54 -0700, Tim Bray wrote: > 2. We encourage the submission of a new round of Paces, each proposing a > single date for acceptance in Atom. How is possible to define relationships between dates, then? I, and some others, find it useful to only require _one_ date in atom:entry, but which date element publishers chooses to put in their feeds is up to them. It is also desirable to gently force publishers to stop producing ambiguous dates, and start sharing semantics. Without any relationships between the dates, this is difficult to get into the specification. What would happen if only two out of four date paces are accepted, for instance? It's good that we're taking a step forward, but I'm not sure that focusing on one date at a time is a good idea in the end, especially not if the goal is to reach consensus on whether to include them or not during this period. It would be better to say that we're first only trying to get consensus on what the dates mean, and when we have a set of date elements we agree on, one could start creating paces that included the date elements and their relationship with each other. Just my two cents. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 14:40:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22864 for ; Thu, 19 Aug 2004 14:40:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIRK8u042230; Thu, 19 Aug 2004 11:27:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIRKAj042229; Thu, 19 Aug 2004 11:27:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIRJKY042222 for ; Thu, 19 Aug 2004 11:27:19 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7JIRM53021068 for ; Thu, 19 Aug 2004 12:27:23 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2P00F4YHXMPK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 19 Aug 2004 12:27:23 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2P00L0NHXLXL@mail.sun.net> for atom-syntax@imc.org; Thu, 19 Aug 2004 12:27:22 -0600 (MDT) Date: Thu, 19 Aug 2004 11:27:31 -0700 From: Tim Bray Subject: Re: Next step on Dates In-reply-to: To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom-Syntax Message-id: <6EFC52AA-F20D-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <0E0F1F40-F163-11D8-99EE-000A95A51C9E@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JIRJKY042223 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Aug 19, 2004, at 11:25 AM, Asbjørn Ulsberg wrote: > It's good that we're taking a step forward, but I'm not sure that > focusing on one date at a time is a good idea in the end, especially > not if the goal is to reach consensus on whether to include them or > not during this period. I'm quite sure that the path we were on was not moving to consensus on a selection of dates. Right now, the one-at-a-time approach seems like the best bet for making progress on this issue. Let's see how it goes. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 19 14:46:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23161 for ; Thu, 19 Aug 2004 14:46:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIWMBt043055; Thu, 19 Aug 2004 11:32:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIWMLU043054; Thu, 19 Aug 2004 11:32:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIWLbO043023 for ; Thu, 19 Aug 2004 11:32:22 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id E98437C1F9; Thu, 19 Aug 2004 21:24:12 +0200 (CEST) To: "Tim Bray" Cc: Atom-Syntax Subject: Re: Next step on Dates References: <0E0F1F40-F163-11D8-99EE-000A95A51C9E@sun.com> <6EFC52AA-F20D-11D8-99EE-000A95A51C9E@sun.com> Message-ID: Date: Thu, 19 Aug 2004 20:33:54 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <6EFC52AA-F20D-11D8-99EE-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 11:27:31 -0700, Tim Bray wrote: > I'm quite sure that the path we were on was not moving to consensus on a > selection of dates. Right now, the one-at-a-time approach seems like > the best bet for making progress on this issue. Let's see how it goes. I agree that one-at-a-time is a good idea, but I'm not sure that discussing their semantics, behaviour, syntax, whether they should be in the core, and whether they should be a part of Atom or not all at once, is a good idea. Seeing how difficult it is to even agree on what the different dates are and mean, we need to take as small steps as possible. The suggested step is imho a little too big. E.g., let's not choose whether any date elements should be a part of Atom yet. Let's just focus on what dates we need in Atom, and what they mean. Then, we can move on to including them in the core, in whatever way we'd like. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 14:47:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23249 for ; Thu, 19 Aug 2004 14:47:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIZns5043596; Thu, 19 Aug 2004 11:35:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIZnsp043595; Thu, 19 Aug 2004 11:35:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIZnbw043589 for ; Thu, 19 Aug 2004 11:35:49 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7JIZq53025628 for ; Thu, 19 Aug 2004 12:35:52 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2P00GFKIBSDY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 19 Aug 2004 12:35:53 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2P00L45IBRXL@mail.sun.net> for atom-syntax@imc.org; Thu, 19 Aug 2004 12:35:52 -0600 (MDT) Date: Thu, 19 Aug 2004 11:36:02 -0700 From: Tim Bray Subject: Re: Next step on Dates In-reply-to: To: Atom-Syntax WG Message-id: <9F25F394-F20E-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <0E0F1F40-F163-11D8-99EE-000A95A51C9E@sun.com> <6EFC52AA-F20D-11D8-99EE-000A95A51C9E@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JIZnbw043590 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Aug 19, 2004, at 11:33 AM, Asbjørn Ulsberg wrote: > Let's just focus on what dates we need in Atom, and what they mean. No. We tried that and failed resoundingly. Asbjørn, please work with us on this one and see if we can make some progress. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 19 15:09:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24981 for ; Thu, 19 Aug 2004 15:09:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIoLpO045929; Thu, 19 Aug 2004 11:50:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIoL86045928; Thu, 19 Aug 2004 11:50:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIoJxB045913 for ; Thu, 19 Aug 2004 11:50:20 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id E89DC7C1F9; Thu, 19 Aug 2004 21:42:10 +0200 (CEST) To: "Dare Obasanjo" , "Julian Reschke" Cc: Atom-Syntax Subject: Re: ID wording References: <20040819141552.39742.qmail@web41211.mail.yahoo.com> Message-ID: Date: Thu, 19 Aug 2004 20:51:57 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20040819141552.39742.qmail@web41211.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 07:15:52 -0700 (PDT), Dare Obasanjo wrote: > Relative URIs not being URIs is a new stance that is showing > up on discussions about this issue on other mailing lists. Okay. I haven't read that anywhere until just now. > As far as I'm aware relative URIs have been considered URIs > for as long as they have existed. Yes, but I can both understand and agree with the notion of them not being so. Either way, I think the Atom specification needs to mention this fact, such as PaceIdConstruct[1] does perfectly: «atom:id MUST NOT be a relative URI». ____ [1] -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 15:11:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25153 for ; Thu, 19 Aug 2004 15:11:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIrvkZ046501; Thu, 19 Aug 2004 11:53:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIrvtR046500; Thu, 19 Aug 2004 11:53:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIrucZ046483 for ; Thu, 19 Aug 2004 11:53:57 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id F143D7C22E; Thu, 19 Aug 2004 21:45:47 +0200 (CEST) Date: Thu, 19 Aug 2004 20:55:35 +0200 To: "Anne van Kesteren" Subject: Re: PaceIdConstruct Cc: Atom-Syntax References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124EEE2.6000703@annevankesteren.nl> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4124EEE2.6000703@annevankesteren.nl> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 20:18:10 +0200, Anne van Kesteren wrote: >> http://www.intertwingly.net/wiki/pie/PaceIdConstruct > > From that page: > > # http://www.example.org/rosé > > That is not a valid URI. However, it is a valid IRI which will become a > recommendation soon[1]. I think that since IRI's are going to be a recommendation shortly, the pace should just replace all occurences of «URI» with «IRI». Then, the example will be correct as well. The fact that atom:id is not going to be dereferencable makes it even easier to deploy IRI's, since they're only going to be stored as UTF-8 somewhere, and not be used in some transport protocol layer to dereference resources. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 15:12:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25337 for ; Thu, 19 Aug 2004 15:12:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIrGZj046372; Thu, 19 Aug 2004 11:53:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JIrGr0046371; Thu, 19 Aug 2004 11:53:16 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i7JIrEuH046359 for ; Thu, 19 Aug 2004 11:53:15 -0700 (PDT) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.55.191] (helo=mx7.freenet.de) by mout2.freenet.de with asmtp (Exim 4.41) id 1Bxs2H-0005hs-JN; Thu, 19 Aug 2004 20:53:17 +0200 Received: from pd9fc509e.dip.t-dialin.net ([217.252.80.158]) by mx7.freenet.de with asmtp (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.41 #1) id 1Bxs2G-0005zB-Uw; Thu, 19 Aug 2004 20:53:17 +0200 Message-ID: <4124F6E7.8050209@rbg.informatik.tu-darmstadt.de> Date: Thu, 19 Aug 2004 20:52:23 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: David Powell CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom-Syntax Subject: Re: Using DC only for informational dates References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> <1092397529.411ca9d96959e@webmail.djpowell.net> <1021337343.20040815024400@djpowell.net> In-Reply-To: <1021337343.20040815024400@djpowell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > I probably wasn't very clear about what I mean by behaviours. > I see Atom as a protocol for the transfer of metadata between agents. > Some fields in atom:entry are part of the protocol, and some are part > of the metadata/data. (The boundaries are a bit blurred though because > all protocol fields are also metadata.) > For example I'd class atom:id as part of the protocol - it is likely > that Atom will specify behaviours of how the Atom protocol interacts > with this field. That's a distinction (between protocol and metadata) well worth to make. Thanks for pointing it out. Now in my opinion the dates from dcterms are all informational metadata about the publishing process that produced a given entry. None of these dates are essential for the protocol - perhaps with the sole exception of dcterms:modified. That's because the date of the last modification is useful for the user agent itself - even if the user is never interested in it. Similarly the date of the last major modification might be useful for the user agent, too, to keep its local cache of entries up-to-date. So I consider both atom:modified and atom:updated to be dates that are useful as part of the protocol. Now one might argue whether a (protocol) atom:modified is indeed the same as a (metadata) dcterms:modified, or if the latter only refers to a modification in terms of the given publishing process whereas the former reflects all modification including the "low-level" ones like e.g. changing the case of an xml:lang attribute's content. At any rate, I would like to see only dates being part of the protocol included in the Atom core. For nice-to-have metadata dates there is always the option of extensions - even if this might result in some kind of overlap between e.g. atom:modified and dcterms:modified. Any further thoughts? Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Thu Aug 19 15:21:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26698 for ; Thu, 19 Aug 2004 15:21:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJ6WxZ049336; Thu, 19 Aug 2004 12:06:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JJ6WJ9049335; Thu, 19 Aug 2004 12:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJ6V64049326 for ; Thu, 19 Aug 2004 12:06:31 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7JJ8NoJ029580; Thu, 19 Aug 2004 15:08:23 -0400 Message-ID: <4124FA38.1020006@intertwingly.net> Date: Thu, 19 Aug 2004 15:06:32 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Thu, 19 Aug 2004 11:15:08 -0400, Sam Ruby > wrote: > >> http://www.intertwingly.net/wiki/pie/PaceIdConstruct > > Ah, brilliant. +1. If there is lots of objections to the «MUST contain» > wording in 4.2.6, I will have no problems with SHOULD. If it is a SHOULD, then atom:origin can't depend on it being there. This was identified as an issue in the original discussion of atom:origin... what currently is spec'ed is not only surprising to some, but actually is broken. See: http://www.imc.org/atom-syntax/mail-archive/msg06269.html http://www.imc.org/atom-syntax/mail-archive/msg07408.html http://www.imc.org/atom-syntax/mail-archive/msg07432.html http://www.imc.org/atom-syntax/mail-archive/msg07438.html - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 19 15:31:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27788 for ; Thu, 19 Aug 2004 15:31:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJImda051352; Thu, 19 Aug 2004 12:18:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JJImfc051351; Thu, 19 Aug 2004 12:18:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJIjmR051326; Thu, 19 Aug 2004 12:18:46 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <41248721.1070500@dehora.net> References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> <41248721.1070500@dehora.net> Date: Thu, 19 Aug 2004 12:13:39 -0700 To: Bill de =?iso-8859-1?Q?h=D3ra?= , Atom WG From: Paul Hoffman / IMC Subject: Re: ID wording Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 11:55 AM +0100 8/19/04, Bill de hÓra wrote: >Ok, how about either, > >"XML Schema descriptions of Atom SHOULD prefer xsi:string to represent IDs. " -1 >or, we just agree to remember that schema coming off this WG will xsi:string. +1 If we have an implementer's guide, that guide should have a section on "implementing schemas for Atom", and "in schemas, IDs act like strings, not URIs" should be there. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 19 15:32:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27855 for ; Thu, 19 Aug 2004 15:32:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJImJL051348; Thu, 19 Aug 2004 12:18:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JJIm8e051347; Thu, 19 Aug 2004 12:18:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJIjmT051326 for ; Thu, 19 Aug 2004 12:18:47 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Thu, 19 Aug 2004 12:18:43 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: On posting new PaceDateSomeName proposals Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the things that has plagued this WG is proposals from individuals that get little support from others WG folks. That is not to say that such proposals are bad, just that the proposers often spend a lot of mailing list traffic soliciting support for their proposals, and that soliciting is difficult to distinguish from disagreement about other related proposals. In this round of date proposals, it would be really nice if each pace *already had* three active proponents who have bought into the semantics. That will reduce the WG traffic and probably greatly reduce the confusion on the list. Yes, this means off-list discussions. No, that doesn't mean "cabal". It means saving time and reading effort for the WG. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 19 15:35:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27932 for ; Thu, 19 Aug 2004 15:35:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJLW21051982; Thu, 19 Aug 2004 12:21:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JJLWuT051981; Thu, 19 Aug 2004 12:21:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJLTVV051970; Thu, 19 Aug 2004 12:21:30 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4C1D2D5A-F208-11D8-BAC6-000A95D9FA7A@bblfish.net> References: <4C1D2D5A-F208-11D8-BAC6-000A95D9FA7A@bblfish.net> Date: Thu, 19 Aug 2004 12:21:35 -0700 To: Henry Story , Atom Syntax From: Paul Hoffman / IMC Subject: Re: extensibility: request for ideas Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This would be a great project. If you could keep a separate web site with the proposals, mocked-up feeds, and so on, and report occasionally on the changes, it would most likely indeed help us stay on track. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 19 15:36:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27967 for ; Thu, 19 Aug 2004 15:36:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJInRj051360; Thu, 19 Aug 2004 12:18:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JJInwA051359; Thu, 19 Aug 2004 12:18:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJIjmP051326; Thu, 19 Aug 2004 12:18:45 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 19 Aug 2004 12:11:43 -0700 To: Eric Scheid , Atom Syntax From: Paul Hoffman / IMC Subject: Re: Syndication of updates and deletions of content Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:27 PM +1000 8/19/04, Eric Scheid wrote: >A delete event fits within the rubric of a full versioning publishing >process, and sits alongside other events like retracted, superceded, >withdrawn, etc. +1 >If I had a situation where I wanted to "delete" some entry I've published, >I'd probably do something like this: > > > ... > DELETED! > Sorry, someone threatened me with a kneecapping > ... > That seems eminently sensible and easy to both write and read. >This raises a question for me though ... if version#1 contains some >elements, but version#2 is missing some of those elements, does this mean >that the true entry is in fact missing those elements? If so, will this bork >the SSFF profile of atom? It means that the whole versioning publishing process needs to be discussed on its own as a well-thought-out extension to Atom. There should be a theory document that is fully agreed-to by a group of people before any angle brackets are first used. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 19 15:37:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28126 for ; Thu, 19 Aug 2004 15:37:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJNkXK052346; Thu, 19 Aug 2004 12:23:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JJNkSe052345; Thu, 19 Aug 2004 12:23:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJNjND052324 for ; Thu, 19 Aug 2004 12:23:45 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7JJPaRe030426 for ; Thu, 19 Aug 2004 15:25:39 -0400 Message-ID: <4124FE41.4050107@intertwingly.net> Date: Thu, 19 Aug 2004 15:23:45 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124FA38.1020006@intertwingly.net> In-Reply-To: <4124FA38.1020006@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sam Ruby wrote: > > Asbjørn Ulsberg wrote: > >> On Thu, 19 Aug 2004 11:15:08 -0400, Sam Ruby >> wrote: >> >>> http://www.intertwingly.net/wiki/pie/PaceIdConstruct >> >> Ah, brilliant. +1. If there is lots of objections to the «MUST >> contain» wording in 4.2.6, I will have no problems with SHOULD. > > If it is a SHOULD, then atom:origin can't depend on it being there. This > was identified as an issue in the original discussion of atom:origin... > what currently is spec'ed is not only surprising to some, but actually > is broken. See: > > http://www.imc.org/atom-syntax/mail-archive/msg06269.html > http://www.imc.org/atom-syntax/mail-archive/msg07408.html > http://www.imc.org/atom-syntax/mail-archive/msg07432.html > http://www.imc.org/atom-syntax/mail-archive/msg07438.html Actually, I should include the following one in the list, as it is the clearest indication of what should be done: http://www.imc.org/atom-syntax/mail-archive/msg07413.html - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 19 16:13:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03371 for ; Thu, 19 Aug 2004 16:13:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJnGtA056210; Thu, 19 Aug 2004 12:49:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JJnGdc056209; Thu, 19 Aug 2004 12:49:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JJnFNE056181 for ; Thu, 19 Aug 2004 12:49:16 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004081919491201600k237me>; Thu, 19 Aug 2004 19:49:12 +0000 Date: Thu, 19 Aug 2004 13:49:11 -0600 Subject: Re: On posting new PaceDateSomeName proposals Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 19, 2004, at 01:18 PM, Paul Hoffman / IMC wrote: > One of the things that has plagued this WG is proposals from > individuals that get little support from others WG folks. That is not > to say that such proposals are bad, just that the proposers often > spend a lot of mailing list traffic soliciting support for their > proposals, and that soliciting is difficult to distinguish from > disagreement about other related proposals. This brings some similar issues to mind: * Silence is difficult to distinguish from agreement ("I agree, but I don't have anything to add") * Silence is difficult to distinguish from indifference * Silence is difficult to distinguish from utter disdain ("This tripe isn't even worth commenting on") Most of the time, it's nice not having every person on the list sending a "+1" or "-1" email in response to every idea, but at other times, especially in situations like this, a few more expressions of agreement or disagreement would probably be helpful. We've been around and around on this issue, and we're probably all getting pretty sick of it, so I can understand not feeling inclined to speak up one way or the other, but unfortunately, we're going to need more than just a handful of people to participate if we're going to lay this issue to rest. So, let me practice what I preach. I'm aware of 3 proposals posted since the last reset of the conversation, and my opinions on them: PaceDateElement: +0.2 PaceDateUpdated: +1 PaceDateSubjective: +1 PaceDateElement just seems a little too vague about what one can expect to find in atom:date. PaceDateUpdated is very similar, only more specific about what the data means. atom:updated is thus clearly distinguishable from any dates from dcterms that a publisher may wish to use in their feed. From owner-atom-syntax@mail.imc.org Thu Aug 19 16:48:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07778 for ; Thu, 19 Aug 2004 16:48:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JKTcBb062376; Thu, 19 Aug 2004 13:29:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JKTcBG062375; Thu, 19 Aug 2004 13:29:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JKTagj062368 for ; Thu, 19 Aug 2004 13:29:37 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4124EEE2.6000703@annevankesteren.nl> References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124EEE2.6000703@annevankesteren.nl> Date: Thu, 19 Aug 2004 13:26:01 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: PaceIdConstruct Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 8:18 PM +0200 8/19/04, Anne van Kesteren wrote: >That is not a valid URI. However, it is a valid IRI which will >become a recommendation soon[1]. Saying "will become" in a context like this is premature. There are many hurdles between "IETF last call" and "accepted as a standard". >Is Atom going to do anything with IRIs? If they are accepted as a standard, this WG should certainly look at them. At 8:55 PM +0200 8/19/04, Asbjørn Ulsberg wrote: >I think that since IRI's are going to be a recommendation shortly, >the pace should just replace all occurences of «URI» with «IRI». >Then, the example will be correct as well. If we follow what you suggest, and IRIs do not become a standard, then neither will Atom. I don't think that's what people here want. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 19 17:06:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09253 for ; Thu, 19 Aug 2004 17:06:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JKmpwQ065918; Thu, 19 Aug 2004 13:48:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JKmpaE065917; Thu, 19 Aug 2004 13:48:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JKmo2w065909 for ; Thu, 19 Aug 2004 13:48:50 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7JKmtil022111 for ; Thu, 19 Aug 2004 14:48:55 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2P00FSOOHIPK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 19 Aug 2004 14:48:55 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2P00KCCOHH0A@mail.sun.net> for atom-syntax@imc.org; Thu, 19 Aug 2004 14:48:54 -0600 (MDT) Date: Thu, 19 Aug 2004 13:49:04 -0700 From: Tim Bray Subject: Re: PaceIdConstruct In-reply-to: <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> To: Atom WG Cc: Joe Gregorio , Robert Sayre , Mark Nottingham , Mark Pilgrim Message-id: <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 19, 2004, at 9:23 AM, Tim Bray wrote: >> http://www.intertwingly.net/wiki/pie/PaceIdConstruct > > My judgment, based on what I've seen in the list, is that everything > here has good (not "rough") consensus except for the final item: > "atom:head MUST contain atom:id". I agree about atom:origin, but as > far as I can recall this is the first time this issue's really been > brought to our attention. > > So, in the spirit of grabbing consensus while we can and moving on, I > think our editors should grab the text (except for the > atom:head/atom:id bit) and plow it into their working-copy drafts > forthwith. -Tim Oops, sorry, I'm getting pushback saying "you're going too fast." So, while I do believe that Sam's draft language matches the consensus I've inferred from the last few weeks of email on this subject, I suppose we should hold on for a bit to give other people a chance to object if I've missed something (note one friendly amendment from Rob Sayre already). -Tim From owner-atom-syntax@mail.imc.org Thu Aug 19 17:21:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10630 for ; Thu, 19 Aug 2004 17:21:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JL7o8n068881; Thu, 19 Aug 2004 14:07:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JL7o2c068880; Thu, 19 Aug 2004 14:07:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JL7ngm068870 for ; Thu, 19 Aug 2004 14:07:49 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 5579D7C1F9; Thu, 19 Aug 2004 23:59:40 +0200 (CEST) Date: Thu, 19 Aug 2004 23:09:52 +0200 To: "Sam Ruby" Subject: Re: PaceIdConstruct Cc: Atom-Syntax References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124FA38.1020006@intertwingly.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4124FA38.1020006@intertwingly.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 15:06:32 -0400, Sam Ruby wrote: >> Ah, brilliant. +1. If there is lots of objections to the «MUST >> contain» wording in 4.2.6, I will have no problems with SHOULD. > > If it is a SHOULD, then atom:origin can't depend on it being there. I agree, so I'm +1 on it, unless everyone else is -1. I just don't want to halt consensus on it, that's all. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 17:25:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10814 for ; Thu, 19 Aug 2004 17:25:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLE0Jl069830; Thu, 19 Aug 2004 14:14:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JLE0Iq069829; Thu, 19 Aug 2004 14:14:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLE0lf069807 for ; Thu, 19 Aug 2004 14:14:00 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004081921135601600k3qhqe>; Thu, 19 Aug 2004 21:13:57 +0000 Date: Thu, 19 Aug 2004 15:13:55 -0600 Subject: Re: On posting new PaceDateSomeName proposals Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 19, 2004, at 01:49 PM, Antone Roundy wrote: > Most of the time, it's nice not having every person on the list > sending a "+1" or "-1" email in response to every idea, but at other > times, especially in situations like this, a few more expressions of > agreement or disagreement would probably be helpful. ... > So, let me practice what I preach. I'm aware of 3 proposals posted > since the last reset of the conversation, and my opinions on them: > > PaceDateElement: +0.2 > PaceDateUpdated: +1 > PaceDateSubjective: +1 > BTW, this message was not even remotely intended as a suggestion that we take a vote or a poll or anything, though having received a comment about it off list, I can see how it looks like one. It's just that I think we're all getting a little jaded by the length of this discussion and feeling less inclined to speak up about what we think of particular ideas. Perhaps the "three person" rule--getting support off list before posting proposals on difficult topics like this--is a better way to gauge opinion without making everyone even more jaded. From owner-atom-syntax@mail.imc.org Thu Aug 19 17:28:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11336 for ; Thu, 19 Aug 2004 17:28:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLH5mA070272; Thu, 19 Aug 2004 14:17:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JLH5jN070271; Thu, 19 Aug 2004 14:17:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLH4i9070265 for ; Thu, 19 Aug 2004 14:17:05 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7JLIxw4003417; Thu, 19 Aug 2004 17:18:59 -0400 Message-ID: <412518D4.6070809@intertwingly.net> Date: Thu, 19 Aug 2004 17:17:08 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> In-Reply-To: <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 19, 2004, at 9:23 AM, Tim Bray wrote: > >>> http://www.intertwingly.net/wiki/pie/PaceIdConstruct >> >> My judgment, based on what I've seen in the list, is that everything >> here has good (not "rough") consensus except for the final item: >> "atom:head MUST contain atom:id". I agree about atom:origin, but as >> far as I can recall this is the first time this issue's really been >> brought to our attention. >> >> So, in the spirit of grabbing consensus while we can and moving on, I >> think our editors should grab the text (except for the >> atom:head/atom:id bit) and plow it into their working-copy drafts >> forthwith. -Tim > > Oops, sorry, I'm getting pushback saying "you're going too fast." So, > while I do believe that Sam's draft language matches the consensus I've > inferred from the last few weeks of email on this subject, I suppose we > should hold on for a bit to give other people a chance to object if I've > missed something (note one friendly amendment from Rob Sayre already). I also made a change (removed an invalid example) based on feedback from Anne van Kesteren [1]. At a minimum, atom:origin is very, very closely related to this issue as it involves the comparison of URIs; furthermore it currently is broken [2]. If we have time, we can discuss it now. Otherwise, we can schedule it for later. - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg08628.html [2] http://www.imc.org/atom-syntax/mail-archive/msg08640.html From owner-atom-syntax@mail.imc.org Thu Aug 19 17:38:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12360 for ; Thu, 19 Aug 2004 17:38:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLQLIo071730; Thu, 19 Aug 2004 14:26:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JLQLCN071729; Thu, 19 Aug 2004 14:26:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLQKwE071712; Thu, 19 Aug 2004 14:26:21 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id E4C7B7C1F9; Fri, 20 Aug 2004 00:18:11 +0200 (CEST) Date: Thu, 19 Aug 2004 23:28:33 +0200 To: "Paul Hoffman / IMC" Subject: Re: PaceIdConstruct Cc: Atom-Syntax References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124EEE2.6000703@annevankesteren.nl> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 13:26:01 -0700, Paul Hoffman / IMC wrote: > If we follow what you suggest, and IRIs do not become a standard, then > neither will Atom. I don't think that's what people here want. Okay, then let's just wait. I'm pretty confident IRIs will become standard before Atom, so whenever they are, Atom can reference them. Right? In the meantime, the example with 'rosé' in a URI should probably be removed, since that is an invalid URI. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 17:39:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12396 for ; Thu, 19 Aug 2004 17:39:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLTZT7072218; Thu, 19 Aug 2004 14:29:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JLTZv7072217; Thu, 19 Aug 2004 14:29:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLTY63072196; Thu, 19 Aug 2004 14:29:34 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 6FD067C1F9; Fri, 20 Aug 2004 00:21:25 +0200 (CEST) To: "Paul Hoffman / IMC" Cc: Atom-Syntax Subject: Re: On posting new PaceDateSomeName proposals References: Message-ID: Date: Thu, 19 Aug 2004 23:31:48 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 12:18:43 -0700, Paul Hoffman / IMC wrote: > One of the things that has plagued this WG is proposals from individuals > that get little support from others WG folks. That is not to say that > such proposals are bad, just that the proposers often spend a lot of > mailing list traffic soliciting support for their proposals, and that > soliciting is difficult to distinguish from disagreement about other > related proposals. I'd just like to note that I did this exact thing with PaceDates, which ended up in PaceDateAsbjornUlsberg and PaceDateAsbjornUlsberg2. Those paces had support from others than myself, but I'm not sure why the others didn't say so on the list. > In this round of date proposals, it would be really nice if each pace > *already had* three active proponents who have bought into the > semantics. That will reduce the WG traffic and probably greatly reduce > the confusion on the list. How should these proponents be named? In the pace? If so, could that be added to the template, so it's not forgotten by the pace creators? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 19 17:51:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13016 for ; Thu, 19 Aug 2004 17:51:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JLei5T073925; Thu, 19 Aug 2004 14:40:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JLeijg073924; Thu, 19 Aug 2004 14:40:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from psmtp.com (exprod6ob1.obsmtp.com [12.158.35.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JLeT4t073882 for ; Thu, 19 Aug 2004 14:40:29 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob1.obsmtp.com ([12.158.35.250]) with SMTP; Thu, 19 Aug 2004 14:40:34 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i7JLeCJI026612; Thu, 19 Aug 2004 14:40:17 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i7JLeCTk026663; Thu, 19 Aug 2004 14:40:12 -0700 (PDT) Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2P00D5UQUZMP@mailsj-v1.corp.adobe.com>; Thu, 19 Aug 2004 14:40:12 -0700 (PDT) Date: Thu, 19 Aug 2004 14:40:11 -0700 From: Larry Masinter Subject: (please reply to uri@w3.org) URI vs Relative URI To: atom-syntax@imc.org Cc: uri@w3.org Message-id: <0I2P00D5VQUZMP@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSGNRrn0jhFAK3KR+W7CqSAnwClsQ== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Some people have been concerned about the community confusion on the terms "URI" and "Relative URI". The question is whether anyone thinks the document http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt is not clear on the definitions of these terms and the usage of the protocol elements. If you have comments about that particular document, please reply to uri@w3.org. Thanks, Larry From owner-atom-syntax@mail.imc.org Thu Aug 19 18:17:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15352 for ; Thu, 19 Aug 2004 18:17:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JM66OP078578; Thu, 19 Aug 2004 15:06:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JM66qI078577; Thu, 19 Aug 2004 15:06:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JM65wn078564; Thu, 19 Aug 2004 15:06:05 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.212]) by mail.mnot.net (Postfix) with ESMTP id 6FD5C727D; Thu, 19 Aug 2004 15:06:10 -0700 (PDT) In-Reply-To: <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> References: <32E505E0-F19C-11D8-B945-000A95DC3D90@mac.com> <86ACB748-F1A7-11D8-99EE-000A95A51C9E@sun.com> <9DE3E098-F1AC-11D8-99EE-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Graham , Paul Hoffman / IMC , Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: ID wording Date: Thu, 19 Aug 2004 15:06:09 -0700 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My intent was not that these words would show up in the spec; rather, that we'd just remember them when writing the schema. Cheers, On Aug 18, 2004, at 11:54 PM, Tim Bray wrote: > > > On Aug 18, 2004, at 11:49 PM, Mark Nottingham wrote: > >> Ah. Can we agree to add this to the list; >> >> - If/when Atom is described with XML Schema, the ID should be a >> xs:string, not xs:anyURI. I.e., the content will be restricted to a >> URI in prose, not in the schema. > > I'm nervous about getting that specific... this feels like it belongs > in an Implementor's Guide or some such. I think we have agreement > that we should provide schemas to help out (although not that they be > normative), and a well-commented entry in such a schema seems like a > good way to do it. -Tim > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Aug 19 18:43:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16646 for ; Thu, 19 Aug 2004 18:43:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMUjWL081970; Thu, 19 Aug 2004 15:30:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JMUj8Y081969; Thu, 19 Aug 2004 15:30:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode03.zonnet.nl (postbode03.zonnet.nl [62.58.50.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMUikh081958 for ; Thu, 19 Aug 2004 15:30:45 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 27977 invoked by uid 10); 19 Aug 2004 22:30:44 -0000 Received: (vexira-qq 27971-36E3C2AD invoked from network) 20 Aug 2004 00:30:44 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode03.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 19 Aug 2004 22:30:44 -0000 Message-ID: <41252A1D.8050607@annevankesteren.nl> Date: Fri, 20 Aug 2004 00:30:53 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Atom Syntax Subject: Atom Feed Autodiscovery Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some points I was wondering about: * Does the TYPE attribute MUST/SHOULD/MAY match the actual MIME type of the referenced file? (Can 'application/xml' work too?) * If a LINK element has TITLE, should that make it more preferred than a LINK element without? * Using "" makes it look like you are referring to the tag. Which is not the case, since both the HEAD and BODY element's start and end tag are optional in HTML. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Aug 19 18:52:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17045 for ; Thu, 19 Aug 2004 18:52:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JMgk8o083896; Thu, 19 Aug 2004 15:42:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JMgkRM083895; Thu, 19 Aug 2004 15:42:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JMgj1F083873 for ; Thu, 19 Aug 2004 15:42:46 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 80577 messnum 7750388 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 19 Aug 2004 22:42:42 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail01.svc.cra.dublin.eircom.net (qp 80577) with SMTP; 19 Aug 2004 22:42:42 -0000 Message-ID: <41252CDF.3060708@dehora.net> Date: Thu, 19 Aug 2004 23:42:39 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom-Syntax Subject: Re: ID wording References: <20040819170228.41368.qmail@web41215.mail.yahoo.com> In-Reply-To: <20040819170228.41368.qmail@web41215.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > I'm not even sure what that means. Should there > also be a means for claiming that something is an > integer but specifying that you shouldn't use it for > arithmetic operations? Perhaps only in the presence of inconsistent or broken implementations of +. cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 19 19:25:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19093 for ; Thu, 19 Aug 2004 19:25:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JNFZ5h088340; Thu, 19 Aug 2004 16:15:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JNFZ0Z088339; Thu, 19 Aug 2004 16:15:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JNFYhL088331 for ; Thu, 19 Aug 2004 16:15:34 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so301388rnl for ; Thu, 19 Aug 2004 16:15:39 -0700 (PDT) Received: by 10.38.102.37 with SMTP id z37mr580064rnb; Thu, 19 Aug 2004 16:15:39 -0700 (PDT) Message-ID: <14be96d3040819161525cf79a3@mail.gmail.com> Date: Thu, 19 Aug 2004 19:15:39 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Anne van Kesteren Subject: Re: Atom Feed Autodiscovery Cc: Atom Syntax In-Reply-To: <41252A1D.8050607@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41252A1D.8050607@annevankesteren.nl> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 20 Aug 2004 00:30:53 +0200, Anne van Kesteren wrote: > > Some points I was wondering about: > > * Does the TYPE attribute MUST/SHOULD/MAY match the actual MIME type of > the referenced file? > (Can 'application/xml' work too?) The answer is two-fold. 1. As per the HTML specification [1] and the Authoritative Metadata best practices document [2], the @type attribute is advisory only. Its purpose is to provide a hint to clients as to what they may reasonably expect at the other end of @href, without dereferencing it. If a client chooses to dereference the @href, its Content-Type is authoritative. 2. The only @type value defined for Atom autodiscovery elements is "application/atom+xml". Any other @type value is not an Atom autodiscovery element. Publishers who use other values are not supporting Atom autodiscovery, and client behavior in such instances is beyond the scope of this specification. [1] http://www.w3.org/TR/REC-html40/struct/links.html#adef-type-A [2] http://www.w3.org/2001/tag/doc/mime-respect.html#specs -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu Aug 19 20:05:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20967 for ; Thu, 19 Aug 2004 20:05:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JNooqs093648; Thu, 19 Aug 2004 16:50:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JNooIp093647; Thu, 19 Aug 2004 16:50:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JNoms5093640 for ; Thu, 19 Aug 2004 16:50:49 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 19 Aug 2004 16:49:23 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: On posting new PaceDateSomeName proposals Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 11:31 PM +0200 8/19/04, Asbjørn Ulsberg wrote: >How should these proponents be named? In the pace? Sure. > If so, could that be added to the template, so it's not forgotten >by the pace creators? We don't need to be that structured. Antone had a separate section in his first two for supporters; others might just put their names somewhere near the top. This isn't a beauty contest, just a way to be sure that the proposals already have enough support to warrant attention. If none of the paces get three people supporting them, Tim and I will have to figure out some other micromanagement scheme to bug you with. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 19 20:15:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21344 for ; Thu, 19 Aug 2004 20:15:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JNw4an095179; Thu, 19 Aug 2004 16:58:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JNw4PH095178; Thu, 19 Aug 2004 16:58:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pulse.betaversion.org ([62.140.213.123]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JNw3pK095157 for ; Thu, 19 Aug 2004 16:58:03 -0700 (PDT) (envelope-from pier@betaversion.org) Received: (qmail 20920 invoked from network); 19 Aug 2004 23:58:05 -0000 Received: from unknown (HELO ?192.168.72.101?) (pier@62.140.203.188) by pulse.betaversion.org with SMTP; 19 Aug 2004 23:58:05 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-836051248; protocol="application/pkcs7-signature" Message-Id: <9C38CA5A-F23B-11D8-B4D3-000A95984AEA@betaversion.org> Cc: Atom Syntax From: Pier Fumagalli Subject: Re: Syndication of updates and deletions of content Date: Fri, 20 Aug 2004 00:58:04 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-1-836051248 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 19 Aug 2004, at 04:27, Eric Scheid wrote: > On 18/8/04 11:30 PM, "Pier Fumagalli" wrote: > >> Good point... Maybe just and are actually pertinent to >> the notification of a removal event. > > A delete event fits within the rubric of a full versioning publishing > process, and sits alongside other events like retracted, superceded, > withdrawn, etc. I'm missing on few core concepts here... What's a rubric, and what is the difference between retracted, withdrawn and deleted... Hmmm... This is getting waaaaay too complicated for me... Pier --Apple-Mail-1-836051248 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwttIjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTA3MDE0MjIwWhcNMDUwMTA2MDE0MjIwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRwaWVyQGJldGF2ZXJzaW9u Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMC/E+M4UqeEBnSTj0AIMX9oMWSo 9Te7VUPPvINPSKKLEElGaottQeJaYRSlfGIjUyXkzTlbw0MFAPaqfU97t+5xeNkighKu7ZcVIPfz AARv5+wp+gON5uSNV2GzP0rPwAbUDIG2zaSonJlN7whVG5fO9G1u0oYaWolpgKUAc3T5P5Gv737L G1iSxrnl9DQlVDIuZWrcgWYX/MFFlf7prXXm6lS08lYhGi0NrIf5SploZzMG+uHHzVDgV8WCTQr1 hXB825VLhnWw4GPFx5qLVgElctVz88S/+t8O/+1kRf3ky8SsewfyCTuDAk4XHzfb7M5bECiZ1yni dhW+sD1y/TsCAwEAAaMxMC8wHwYDVR0RBBgwFoEUcGllckBiZXRhdmVyc2lvbi5vcmcwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAjeSEnk3U1P46rHiBGJP7StkQg/DVkw4ModEYCEwxm 8QYxQPGMciXn2goZ5ahK6Uu8Rfa+ZPSxV96VFsOlc3oFF02VYsrRy+xJukuSMY0z/0UvHnTZmVfm CJpxMoVMYQO3fC2XdmCNASu8FbvOgaS71fQf3b0wgebLeLROR7u5XjCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC20iMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxOTIzNTgwNFowIwYJKoZIhvcNAQkEMRYEFHw4 1O8gzIOtsZJC5E7/+A/RnXEHMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLbSIwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC20iMA0GCSqGSIb3DQEBAQUABIIBAHqM if6xAXE96KRXNNCgKClngMK7H+cKIOFN2gxikDG17cru6q3hr8OMDgBdt/z0qQ/T6a5lpu4L3phJ VNwIWoB/APKmUwsrHbgnVlrK2yivmp7cZqazbFCf28MUgn8QlNhP5c4O17h6IRlihz/WUtnDKxiL ESORhPx1itrE+finKsBq2hzvAjZEgUyz9ePpegJWbOpvfTNIQVYlIiFGfpLuj/QTFfJLWlughrxc JKtEvJntluRHfIjjgmVk34qbMTHeMQHobIwgOp6datRqqEFauWxzbZGeUvhZHt20uQTQmVSpgXYJ NpgOaJ58cBV4nWwt+Y0juvBsETr+cKbNLKkAAAAAAAA= --Apple-Mail-1-836051248-- From owner-atom-syntax@mail.imc.org Thu Aug 19 21:11:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23427 for ; Thu, 19 Aug 2004 21:11:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K0u7w5003307; Thu, 19 Aug 2004 17:56:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K0u700003306; Thu, 19 Aug 2004 17:56:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K0u4kA003289 for ; Thu, 19 Aug 2004 17:56:06 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 20 Aug 2004 11:02:51 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 Aug 2004 10:56:01 +1000 Subject: Re: PaceDateUpdated posted From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20/8/04 3:11 AM, "Antone Roundy" wrote: > http://www.intertwingly.net/wiki/pie/PaceDateUpdated overall +1, with some caveats. > "Updated" is the most useful single date for enabling meaningful > sort order. I don't care about "sort order". I do care about receiving data signalling that an entry has has a major change according the the publisher. In other words, don't get hung up with "sort order". It's a red herring. > atom:entry elements MUST contain exactly one atom:date element. The > content of this element MUST conform to the Date and Time format > defined in [WWW]RFC 3339. This first MUST requirement is too much since the entry may have never been updated. I do agree though that once an entry has been updated, all subsequent entries should have the latest updated value. If an publishing implementation doesn't facilitate the concept of "updated" (vs modified), it shouldn't be forced to fill this date field with junk values (some will force 'modified' into it for every minor change, others will instead insert the value of 'first published' into it for every subsequent version ... far far better they simply omit the element completely). > Consumers MAY choose to sort based on this value. If the value of > atom:updated for an atom:entry changes, consumers MAY choose to > continue to sort based on the original value rather than the new value. > If atom:updated specifies a future date, consumers MAY choose not to > display entries until the date specified. This whole "sorting" business is a red herring. My understanding of 'updated' is that it signals a major update, what the user-agent does with that is an implementation detail. e. From owner-atom-syntax@mail.imc.org Thu Aug 19 21:42:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25051 for ; Thu, 19 Aug 2004 21:42:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K1WK9P009741; Thu, 19 Aug 2004 18:32:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K1WKLY009740; Thu, 19 Aug 2004 18:32:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K1WKx2009726 for ; Thu, 19 Aug 2004 18:32:20 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <20040820013220013005o9tge>; Fri, 20 Aug 2004 01:32:21 +0000 Date: Thu, 19 Aug 2004 19:32:19 -0600 Subject: Re: PaceDateUpdated posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 19, 2004, at 06:56 PM, Eric Scheid wrote: > On 20/8/04 3:11 AM, "Antone Roundy" wrote: >> "Updated" is the most useful single date for enabling meaningful >> sort order. > > I don't care about "sort order". I do care about receiving data > signalling > that an entry has has a major change according the the publisher. In > other > words, don't get hung up with "sort order". It's a red herring. "One man's red herring..." I could be wrong, but my impression has been that a lot of people ARE interested in using some date element for sorting--in fact that it's a primary use of dates. Out of curiosity, other than signaling major changes, is there anything else you want to do with dates (possibly including other dates that "updated")? >> atom:entry elements MUST contain exactly one atom:date element. The >> content of this element MUST conform to the Date and Time format >> defined in [WWW]RFC 3339. > > This first MUST requirement is too much I made it a MUST on the assumption that we're only going to be able to get consensus on one objective date, and perhaps one subjective one. If we manage to get consensus on more than one, then we should discuss which to require, or whether to require at least one without specifying which. > since the entry may have never been updated. If we only get one date construct (and if this is it), then we'll have to use a slightly loose operational definition of "updated" which includes updating from non-existence to existence. By that definition, creation == the first update. > If an publishing > implementation doesn't facilitate the concept of "updated" (vs > modified), it > shouldn't be forced to fill this date field with junk values (some will > force 'modified' into it for every minor change, others will instead > insert > the value of 'first published' into it for every subsequent version > ... far > far better they simply omit the element completely). Unless we require nothing more than a subjective or very loosely objective date, some publishing implementations aren't going to be able to be precise[1], no matter what ends up in the spec. The question is whether they'll be able to be sufficiently accurate[1] to meet the goals of date constructs, and how we should spec things to maximize accuracy. >> Consumers MAY choose to sort based on this value. If the value of >> atom:updated for an atom:entry changes, consumers MAY choose to >> continue to sort based on the original value rather than the new >> value. >> If atom:updated specifies a future date, consumers MAY choose not to >> display entries until the date specified. > > This whole "sorting" business is a red herring. My understanding of > 'updated' is that it signals a major update, what the user-agent does > with > that is an implementation detail. Based on suggestions from Sam, I've altered that paragraph so that it's more of a warning to producers than a suggestion for implementation details. [1] http://www.imc.org/atom-syntax/mail-archive/msg08457.html From owner-atom-syntax@mail.imc.org Thu Aug 19 22:37:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27153 for ; Thu, 19 Aug 2004 22:37:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K2NmlK017088; Thu, 19 Aug 2004 19:23:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K2NmDm017087; Thu, 19 Aug 2004 19:23:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K2NlGd017071 for ; Thu, 19 Aug 2004 19:23:47 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1Bxz4D-0001KL-Db; Fri, 20 Aug 2004 02:23:45 +0000 Message-ID: <412560AD.3030700@franklinmint.fm> Date: Thu, 19 Aug 2004 22:23:41 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pier Fumagalli CC: Eric Scheid , Atom Syntax Subject: Re: Syndication of updates and deletions of content References: <9C38CA5A-F23B-11D8-B4D3-000A95984AEA@betaversion.org> In-Reply-To: <9C38CA5A-F23B-11D8-B4D3-000A95984AEA@betaversion.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pier Fumagalli wrote: > On 19 Aug 2004, at 04:27, Eric Scheid wrote: > >> On 18/8/04 11:30 PM, "Pier Fumagalli" wrote: >> >>> Good point... Maybe just and are actually pertinent to >>> the notification of a removal event. >> >> >> A delete event fits within the rubric of a full versioning publishing >> process, and sits alongside other events like retracted, superceded, >> withdrawn, etc. > > > I'm missing on few core concepts here... What's a rubric, and what is > the difference between retracted, withdrawn and deleted... > > Hmmm... This is getting waaaaay too complicated for me... Eric was pointing out that accurate representations of such actions are complicated. Did you delete the linked HTML page? You obviously didn't delete the Atom Entry, but all the other dates refer to the time the Entry was changed in some way. A meaningful element requires a bigger commitment from publishers than the WG is comfortable with, IMO. An alternative strategy would be to consider log file: time: foo; resource: quux; action: created time: bar; resource: quux; action: modified time: baz; resource: quux; action: deleted ... It would be a lot easier to syndicate that log file (each permalink would be a fragment identifier #) than it would be to actually track the state of the resource. If you really, really need to track that resource, we have no established practice to draw on. So you (and the market in general) will have to figure out an extension for that. Sorry! Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 19 23:36:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29667 for ; Thu, 19 Aug 2004 23:36:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K3Nmc0025205; Thu, 19 Aug 2004 20:23:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K3NmQ4025204; Thu, 19 Aug 2004 20:23:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from spider.tela.com (spider.tela.com [206.98.7.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K3NlhN025170 for ; Thu, 19 Aug 2004 20:23:47 -0700 (PDT) (envelope-from lance@brainopolis.com) Received: from [192.168.0.20] (c-24-31-15-65.mn.client2.attbi.com [24.31.15.65]) by spider.tela.com (Postfix) with ESMTP id 67AF6111DE88 for ; Thu, 19 Aug 2004 22:23:46 -0500 (CDT) Message-ID: <41256EC1.4090001@brainopolis.com> Date: Thu, 19 Aug 2004 22:23:45 -0500 From: Lance Lavandowska User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceDateSubjective posted References: <258384BE-F203-11D8-B4D4-003065EA6144@geckotribe.com> In-Reply-To: <258384BE-F203-11D8-B4D4-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > Don't worry, the proposed name for the element is not "atom:subjective". > > http://www.intertwingly.net/wiki/pie/PaceDateSubjective > > atom:entry elements MAY contain an atom:date element but MUST NOT > contain more than one. The content of this element MUST conform to the > Date and Time format defined in [WWW]RFC 3339. What is the rationale for "MUST NOT contain more than one?" Given the reasons for this element perhaps there would be a need for more than one subjective date. Using the car model, there may be one date to describe the model (a 2005 Ford Mustang) and another to indicate when the car was made available for sale (September 2004). Lance From owner-atom-syntax@mail.imc.org Thu Aug 19 23:37:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29729 for ; Thu, 19 Aug 2004 23:37:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K3IWl1024434; Thu, 19 Aug 2004 20:18:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K3IWXR024433; Thu, 19 Aug 2004 20:18:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailgw.afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K3ITUv024401 for ; Thu, 19 Aug 2004 20:18:31 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.2] (HELO afc.gov.au) by mailgw.afc.gov.au (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1349635 for atom-syntax@imc.org; Fri, 20 Aug 2004 13:18:26 +1000 Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1473211 for atom-syntax@imc.org; Fri, 20 Aug 2004 13:18:25 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 Aug 2004 13:18:02 +1000 Subject: Re: PaceDateUpdated posted From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20/8/04 11:32 AM, "Antone Roundy" wrote: >> I don't care about "sort order". I do care about receiving data signalling >> that an entry has has a major change according the the publisher. In other >> words, don't get hung up with "sort order". It's a red herring. >> > "One man's red herring..." I could be wrong, but my impression has been that > a lot of people ARE interested in using some date element for sorting--in fact > that it's a primary use of dates. Out of curiosity, other than signaling > major changes, is there anything else you want to do with dates (possibly > including other dates that "updated")? Well, it depends on whether we assume there are other date elements or not. I would want to sort on publishing date or subjective content date (amongst other things, like sort by category, author etc). Generally speaking, I would sort on subjective content date, but this is with the assumed context of seeing each feed in isolation from other feeds (thus Pepys' diary wouldn't be shoved down below everything else). e. From owner-atom-syntax@mail.imc.org Fri Aug 20 00:52:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03234 for ; Fri, 20 Aug 2004 00:52:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K4cdT0036109; Thu, 19 Aug 2004 21:38:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K4cdj2036108; Thu, 19 Aug 2004 21:38:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K4cco4036099 for ; Thu, 19 Aug 2004 21:38:39 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004082004384001600k3fj8e>; Fri, 20 Aug 2004 04:38:40 +0000 Date: Thu, 19 Aug 2004 22:38:39 -0600 Subject: Re: PaceDateSubjective posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <41256EC1.4090001@brainopolis.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 19, 2004, at 09:23 PM, Lance Lavandowska wrote: >> Don't worry, the proposed name for the element is not >> "atom:subjective". >> http://www.intertwingly.net/wiki/pie/PaceDateSubjective >> atom:entry elements MAY contain an atom:date element but MUST NOT >> contain more than one. The content of this element MUST conform to >> the Date and Time format defined in [WWW]RFC 3339. > > What is the rationale for "MUST NOT contain more than one?" Given the > reasons for this element perhaps there would be a need for more than > one subjective date. Using the car model, there may be one date to > describe the model (a 2005 Ford Mustang) and another to indicate when > the car was made available for sale (September 2004). > In the car example, dcterms:available would be more appropriate to when it was available for sale--certainly that is not a subjective date. I suppose there probably are cases were one might want to attach multiple subjective dates to an entry, but I suspect that they are rare. Limiting it to one is partly just to stick with how just about everything else has always been done in syndication feeds, and partly to avoid requiring everyone to deal with complexity that few people will need. From owner-atom-syntax@mail.imc.org Fri Aug 20 01:14:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04423 for ; Fri, 20 Aug 2004 01:14:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K53oKK040321; Thu, 19 Aug 2004 22:03:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K53oT9040320; Thu, 19 Aug 2004 22:03:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K53ln9040311 for ; Thu, 19 Aug 2004 22:03:49 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 19 Aug 2004 22:03:52 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: PaceDateUpdated posted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:18 PM +1000 8/20/04, Eric Scheid wrote: >Well, it depends on whether we assume there are other date elements or not. Let's not assume that we know that. The WG has definitely not decided for "one date only", and has definitely not decided for "multiple dates". For example, the two proposals so far (UpdatedAsChosenByThePoster and SubjectiveBasedOnContent) can exist together with no problem, or could each be the only date in an entry. Other combinations might not work together well. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Aug 20 04:01:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25616 for ; Fri, 20 Aug 2004 04:01:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K7lorO086988; Fri, 20 Aug 2004 00:47:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K7loIl086987; Fri, 20 Aug 2004 00:47:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode01.zonnet.nl (postbode01.zonnet.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K7lnFI086877 for ; Fri, 20 Aug 2004 00:47:50 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 32467 invoked by uid 10); 20 Aug 2004 07:47:41 -0000 Received: (vexira-qq 32448-F355B96F invoked from network) 20 Aug 2004 09:47:41 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode01.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 20 Aug 2004 07:47:41 -0000 Message-ID: <4125ACA3.1070400@annevankesteren.nl> Date: Fri, 20 Aug 2004 09:47:47 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: Re: ID wording References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Greetings again. Thanks for keeping the moratorium on ID discussion. I > thought it would be best to do a sanity check to be sure people were in > agreement on what it seems the consensus so far was. > > - The format for IDs is going to be URIs, not plain strings. +1 > - IDs must not change over time. +1 > - Even though the format is a URI, the IDs are not expected to be > dereferencable (although they might be). +1 > - IDs MUST be compared character-by-character, no case-mapping, no %xx > conversion, and so on. -1. If they are URIs, why can't we treat them as such? > - Receiving and gateway systems MUST NOT alter IDs in any way. +1 -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Fri Aug 20 04:03:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25686 for ; Fri, 20 Aug 2004 04:03:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K7qJhc090234; Fri, 20 Aug 2004 00:52:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K7qJQL090233; Fri, 20 Aug 2004 00:52:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode03.zonnet.nl (postbode03.zonnet.nl [62.58.50.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K7qI2E090149 for ; Fri, 20 Aug 2004 00:52:19 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 9927 invoked by uid 10); 20 Aug 2004 07:52:13 -0000 Received: (vexira-qq 09918-FF6BA8FA invoked from network) 20 Aug 2004 09:52:13 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode03.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 20 Aug 2004 07:52:13 -0000 Message-ID: <4125ADB3.2060400@annevankesteren.nl> Date: Fri, 20 Aug 2004 09:52:19 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Sam Ruby CC: Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> In-Reply-To: <4124C3FC.80000@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > http://www.intertwingly.net/wiki/pie/PaceIdConstruct # URI references identifying entries and feeds are compared when # determining whether a entry or feed is the same as one seen before. # [Definition: The two URIs are treated as strings, and they are # identical if and only if the strings are identical, that is, if they # are the same sequence of characters. ] The comparison is # case-sensitive, and no %-escaping is done or undone. # # A consequence of this is that URI references which are not identical # in this sense may resolve to the same resource. Examples include URI # references which differ only in case or %-escaping. Note that # relative URIs are not allowed as ids. Replacement of XML character # and entity references must be done before any comparison. I don't see why we have to treat URIs as strings. Normalizing them as Mark Pilgrim explained[1] seems like a more sensible and correct thing to do. It just doesn't make sense to treat the following two example is being different: http://example.org/ http://EXAMLE.org/ -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Fri Aug 20 04:11:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26105 for ; Fri, 20 Aug 2004 04:11:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K81Eu0094818; Fri, 20 Aug 2004 01:01:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K81EWb094817; Fri, 20 Aug 2004 01:01:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode03.zonnet.nl (postbode03.zonnet.nl [62.58.50.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K81DZj094776 for ; Fri, 20 Aug 2004 01:01:13 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 25021 invoked by uid 10); 20 Aug 2004 08:01:08 -0000 Received: (vexira-qq 25014-6F03C57F invoked from network) 20 Aug 2004 10:01:08 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode03.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 20 Aug 2004 08:01:08 -0000 Message-ID: <4125AFC3.2090101@annevankesteren.nl> Date: Fri, 20 Aug 2004 10:01:07 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Sam Ruby CC: Tim Bray , Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> <412518D4.6070809@intertwingly.net> In-Reply-To: <412518D4.6070809@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I also made a change (removed an invalid example) based on feedback > from Anne van Kesteren [1]. I still see that invalid URI. Actually, I see a lot of invalid URIs: # If the entity eacute has been defined to be é, the atom:id elements # below all contain the same URI reference, http://example.org/rosé. # # * http://example.org/rosé # * http://example.org/rosé # * http://example.org/rosé # * http://example.org/rosé # * http://example.org/rosé After the XML parser has done it's job, these are all invalid URIs, but valid IRIs. I suggest that you remove that set of examples. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Fri Aug 20 04:13:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26173 for ; Fri, 20 Aug 2004 04:13:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K80jlV094600; Fri, 20 Aug 2004 01:00:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K80jgA094599; Fri, 20 Aug 2004 01:00:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode01.zonnet.nl (postbode01.zonnet.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K80ha4094550 for ; Fri, 20 Aug 2004 01:00:44 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 21251 invoked by uid 10); 20 Aug 2004 08:00:39 -0000 Received: (vexira-qq 21244-954ABF96 invoked from network) 20 Aug 2004 10:00:39 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode01.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 20 Aug 2004 08:00:39 -0000 Message-ID: <4125AFA9.1010800@annevankesteren.nl> Date: Fri, 20 Aug 2004 10:00:41 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Anne van Kesteren CC: Sam Ruby , Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> In-Reply-To: <4125ADB3.2060400@annevankesteren.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> http://www.intertwingly.net/wiki/pie/PaceIdConstruct > > # URI references identifying entries and feeds are compared when > # determining whether a entry or feed is the same as one seen before. > # [Definition: The two URIs are treated as strings, and they are > # identical if and only if the strings are identical, that is, if they > # are the same sequence of characters. ] The comparison is > # case-sensitive, and no %-escaping is done or undone. > # > # A consequence of this is that URI references which are not identical > # in this sense may resolve to the same resource. Examples include URI > # references which differ only in case or %-escaping. Note that > # relative URIs are not allowed as ids. Replacement of XML character > # and entity references must be done before any comparison. > > I don't see why we have to treat URIs as strings. Normalizing them as > Mark Pilgrim explained[1] seems like a more sensible and correct thing > to do. It just doesn't make sense to treat the following two example is > being different: > > http://example.org/ > http://EXAMLE.org/ [1] -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Fri Aug 20 04:15:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26302 for ; Fri, 20 Aug 2004 04:15:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K84Ylj096462; Fri, 20 Aug 2004 01:04:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K84YZ0096461; Fri, 20 Aug 2004 01:04:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7K84UgI096411 for ; Fri, 20 Aug 2004 01:04:33 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 18605 invoked by uid 65534); 20 Aug 2004 08:04:25 -0000 Received: from pD9FF00DE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.0.222) by mail.gmx.net (mp001) with SMTP; 20 Aug 2004 10:04:25 +0200 X-Authenticated: #1915285 Message-ID: <4125B086.8040508@gmx.de> Date: Fri, 20 Aug 2004 10:04:22 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: Paul Hoffman / IMC , Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> In-Reply-To: <4125ACA3.1070400@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: >> - IDs MUST be compared character-by-character, no case-mapping, no %xx >> conversion, and so on. +1 > -1. If they are URIs, why can't we treat them as such? Define "treat them as such". There are many ways to compare URIs, some of which require knowledge of the underlying scheme. What kind of comparison would you suggest instead of char-by-char? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 20 04:22:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26721 for ; Fri, 20 Aug 2004 04:22:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K8BqCR000134; Fri, 20 Aug 2004 01:11:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K8BqWQ000132; Fri, 20 Aug 2004 01:11:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postbode01.zonnet.nl (postbode01.zonnet.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K8Bptj099925 for ; Fri, 20 Aug 2004 01:11:51 -0700 (PDT) (envelope-from mail@annevankesteren.nl) Received: (qmail 6888 invoked by uid 10); 20 Aug 2004 08:11:46 -0000 Received: (vexira-qq 06873-41A6A609 invoked from network) 20 Aug 2004 10:11:45 +0200 Received: from unknown (HELO [127.0.0.1]) ([81.58.242.28]) (envelope-sender ) by postbode01.zonnet.nl (qmail-ldap-1.03) with SMTP for < >; 20 Aug 2004 08:11:45 -0000 Message-ID: <4125B244.1090006@annevankesteren.nl> Date: Fri, 20 Aug 2004 10:11:48 +0200 From: Anne van Kesteren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: nl, en MIME-Version: 1.0 To: Julian Reschke CC: Paul Hoffman / IMC , Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> In-Reply-To: <4125B086.8040508@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.21; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> -1. If they are URIs, why can't we treat them as such? > > Define "treat them as such". There are many ways to compare URIs, some > of which require knowledge of the underlying scheme. What kind of > comparison would you suggest instead of char-by-char? The one which requires knowledge of the underlying scheme. Since in that case you are actually comparing URIs, not just the bytes that created the URI in which case you have used a simple string instead. Mark Pilgrim does a better job than me: -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Fri Aug 20 04:29:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27220 for ; Fri, 20 Aug 2004 04:29:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K8JFJb003371; Fri, 20 Aug 2004 01:19:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K8JFkU003370; Fri, 20 Aug 2004 01:19:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pulse.betaversion.org ([62.140.213.123]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7K8JE3H003342 for ; Fri, 20 Aug 2004 01:19:14 -0700 (PDT) (envelope-from pier@betaversion.org) Received: (qmail 3040 invoked from network); 20 Aug 2004 08:19:11 -0000 Received: from unknown (HELO ?10.11.155.45?) (pier@62.140.213.2) by pulse.betaversion.org with SMTP; 20 Aug 2004 08:19:11 -0000 In-Reply-To: <412560AD.3030700@franklinmint.fm> References: <9C38CA5A-F23B-11D8-B4D3-000A95984AEA@betaversion.org> <412560AD.3030700@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-866117251; protocol="application/pkcs7-signature" Message-Id: <9CF4CE78-F281-11D8-B4D3-000A95984AEA@betaversion.org> Cc: Atom Syntax , Eric Scheid From: Pier Fumagalli Subject: Re: Syndication of updates and deletions of content Date: Fri, 20 Aug 2004 09:19:10 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-866117251 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 20 Aug 2004, at 03:23, Robert Sayre wrote: > Pier Fumagalli wrote: >> On 19 Aug 2004, at 04:27, Eric Scheid wrote: >>> On 18/8/04 11:30 PM, "Pier Fumagalli" wrote: >>> >>>> Good point... Maybe just and are actually pertinent >>>> to >>>> the notification of a removal event. >>> >>> >>> A delete event fits within the rubric of a full versioning publishing >>> process, and sits alongside other events like retracted, superceded, >>> withdrawn, etc. >> I'm missing on few core concepts here... What's a rubric, and what is >> the difference between retracted, withdrawn and deleted... >> Hmmm... This is getting waaaaay too complicated for me... > > Eric was pointing out that accurate representations of such actions > are complicated. Did you delete the linked HTML page? You obviously > didn't delete the Atom Entry, but all the other dates refer to the > time the Entry was changed in some way. Absolutely... I work for a publication company... NOTHING gets ever "deleted" (ever - ever - ever). The "deletion" in a syndication feed simply means "if you, who subscribed to this feed, noticed that I published this entry, and did something about it, please notice that _now_ you won't be able to access that resource anymore" (relatively speaking, the entry has been deleted in relation to the subscriber of the syndication feed). > A meaningful element requires a bigger commitment from > publishers than the WG is comfortable with, IMO. Fair enough. For our internal use, then, we'll draft up something on our own... You're probably right. It shifts the meaning of a syndication feed from "tell me what you've got" to "tell me what you've done", which is a pretty substantial change. Pier --Apple-Mail-2-866117251 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwttIjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTA3MDE0MjIwWhcNMDUwMTA2MDE0MjIwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRwaWVyQGJldGF2ZXJzaW9u Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMC/E+M4UqeEBnSTj0AIMX9oMWSo 9Te7VUPPvINPSKKLEElGaottQeJaYRSlfGIjUyXkzTlbw0MFAPaqfU97t+5xeNkighKu7ZcVIPfz AARv5+wp+gON5uSNV2GzP0rPwAbUDIG2zaSonJlN7whVG5fO9G1u0oYaWolpgKUAc3T5P5Gv737L G1iSxrnl9DQlVDIuZWrcgWYX/MFFlf7prXXm6lS08lYhGi0NrIf5SploZzMG+uHHzVDgV8WCTQr1 hXB825VLhnWw4GPFx5qLVgElctVz88S/+t8O/+1kRf3ky8SsewfyCTuDAk4XHzfb7M5bECiZ1yni dhW+sD1y/TsCAwEAAaMxMC8wHwYDVR0RBBgwFoEUcGllckBiZXRhdmVyc2lvbi5vcmcwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAjeSEnk3U1P46rHiBGJP7StkQg/DVkw4ModEYCEwxm 8QYxQPGMciXn2goZ5ahK6Uu8Rfa+ZPSxV96VFsOlc3oFF02VYsrRy+xJukuSMY0z/0UvHnTZmVfm CJpxMoVMYQO3fC2XdmCNASu8FbvOgaS71fQf3b0wgebLeLROR7u5XjCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC20iMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgyMDA4MTkxMFowIwYJKoZIhvcNAQkEMRYEFKDp 0lmc+o+SwOoc/oZay4LD0ngKMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLbSIwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC20iMA0GCSqGSIb3DQEBAQUABIIBAItl JguGsQCT2jZp/bcTHNCWvktdKH6GiU84PxNlqwgwQYaRlpYMU5achIaE6rMQcU4F0zA1vU49MqVi LeCF+rzHHbVe8Rkv8OhQ0/P79wGM3I7avrINSbubmn3c+lcL7FrDJiH7qVEOfer97KUD0om8cQJj qrAlr/VGlc9HRLy9NDFEHD2+AaZb+3wykPHsuJKyYMLkrYctlmidps0LnzMF2Dor6jbn1qH8uhAG Kgh8KeUNKR4h7wxvhpAcvxLvSRVRgwfENhOWpxcCYjboXaM6so6rQLyIY9fUBdfV/q0581aE+wcg MxJOaxm6WnDcwJriGU+phIe/pb7WxSB/l/sAAAAAAAA= --Apple-Mail-2-866117251-- From owner-atom-syntax@mail.imc.org Fri Aug 20 04:30:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27256 for ; Fri, 20 Aug 2004 04:30:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K8JhEW003563; Fri, 20 Aug 2004 01:19:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K8JhZ9003562; Fri, 20 Aug 2004 01:19:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7K8JgBL003498 for ; Fri, 20 Aug 2004 01:19:42 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 15937 invoked by uid 65534); 20 Aug 2004 08:19:37 -0000 Received: from pD9FF00DE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.0.222) by mail.gmx.net (mp011) with SMTP; 20 Aug 2004 10:19:37 +0200 X-Authenticated: #1915285 Message-ID: <4125B40B.3060505@gmx.de> Date: Fri, 20 Aug 2004 10:19:23 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> In-Reply-To: <4125B244.1090006@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: >>> -1. If they are URIs, why can't we treat them as such? >> >> >> Define "treat them as such". There are many ways to compare URIs, some >> of which require knowledge of the underlying scheme. What kind of >> comparison would you suggest instead of char-by-char? > > > The one which requires knowledge of the underlying scheme. Since in that > case you are actually comparing URIs, not just the bytes that created > the URI in which case you have used a simple string instead. > > Mark Pilgrim does a better job than me: > > So, unless Atom requires one or several specific schemes, how is a generic recipient supposed to do that comparison? BTW: I disagree with Mark's suggestion (or with the statement that there is consensus for) requiring publishers to canonicalize. As far as I can tell, there's still an ongoing debate over it. As a matter of fact, XML-NS is using URIs for exactly the same purpose (identification and disambiguation), and guess what comparison method has been selected? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 20 04:58:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28436 for ; Fri, 20 Aug 2004 04:57:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K8iAdE013636; Fri, 20 Aug 2004 01:44:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K8iALR013635; Fri, 20 Aug 2004 01:44:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K8i9Hm013625 for ; Fri, 20 Aug 2004 01:44:09 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 57F7F727D; Fri, 20 Aug 2004 01:44:10 -0700 (PDT) In-Reply-To: <4124C3FC.80000@intertwingly.net> References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceIdConstruct Date: Fri, 20 Aug 2004 01:44:07 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7K8i9Hm013628 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Sam, Looks good overall. A few questions and editorial notes; > An Identification construct is an element whose content identifies the > parent element of the construct. Its content MUST be a URI, subject to > the following rules: > • It conveys a permanent, universally unique identifier for its parent > element This is redundant, considering the text above. > • It MUST be universally unique, which means that it must be unique > both at the time of creation and in the future. > • It MUST NOT change over time, even if the parent feed or entry > element is relocated, migrated, syndicated, republished, exported or > imported. Is this a closed list, or are these examples? It may be good to make it something like "...is changed (e.g., ...)" > • atom:id MUST NOT be a relative URI (see "absoluteURI" in RFC-2369, > section 3) RFC2396? > The URI scheme of an Identification construct MAY be a dereferencable > URL scheme (like HTTP), but MUST NOT be expected to be one. That means > that atom:id MUST NOT be expected to be dereferencable; it is just an > identifier. > > If the identified resource is served dynamically, the content of an > Identification construct MUST be created only once and then stored > along with the resource. The content of an Identification construct > MUST NOT be created dynamically. "Dynamic" isn't a good term to use in conjunction with the Web; it's not precisely defined and can be very misleading. Beyond that, I'm having difficulty parsing this; can you explain? > URI references identifying entries and feeds are compared when > determining whether a entry or feed is the same as one seen before. > [Definition: The two URIs are treated as strings, and they are > identical if and only if the strings are identical, that is, if they > are the same sequence of characters. ] The comparison is > case-sensitive, and no %-escaping is done or undone. > > A consequence of this is that URI references which are not identical > in this sense may resolve to the same resource. Examples include URI > references which differ only in case or %-escaping. Note that relative > URIs are not allowed as ids. Replacement of XML character and entity > references must be done before any comparison. It's likely I'll need to rewrite this for style, but I think the content is sound. Regarding the examples, I'm not crazy about putting so many in the middle of the draft, especially as a list; they'll tend to get in the way of the other content. A few possible ways around this (not mutually exclusive): - incorporate a variety of id's into the main example(s) - collapse them into prose rather than a list - add an appendix - put them in an implementer's guide Thoughts? > As defined in "3.5 Identification Construct", atom:id, MUST NOT > change over time, even if other representations of the entry (such as > a web representation pointed to by the entry's atom:link element) are > relocated. For a given entry, the atom:id element's content MUST be > stable across all Atom documents published by the same entity. This > means that if the entry is represented in many different feeds > simultaneously, the atom:id of these entries MUST be the same. Also, > if the entry is relocated, migrated, syndicated, republished, exported > or imported, the atom:id MUST NOT change. I'm OK with reminding people of the implications of this, but repeating the text wholesale doesn't add a lot of value, and restating requirements isn't good practice. Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Aug 20 05:12:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29142 for ; Fri, 20 Aug 2004 05:12:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K8tgD8018458; Fri, 20 Aug 2004 01:55:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K8tgsJ018457; Fri, 20 Aug 2004 01:55:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7K8tf23018389 for ; Fri, 20 Aug 2004 01:55:41 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040820085535.57226.qmail@web41209.mail.yahoo.com> Received: from [67.168.130.167] by web41209.mail.yahoo.com via HTTP; Fri, 20 Aug 2004 01:55:35 PDT Date: Fri, 20 Aug 2004 01:55:35 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID wording To: Anne van Kesteren , Julian Reschke Cc: Paul Hoffman / IMC , Atom WG In-Reply-To: <4125B244.1090006@annevankesteren.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Anne van Kesteren wrote: > > > Define "treat them as such". There are many ways > to compare URIs, some > > of which require knowledge of the underlying > scheme. What kind of > > comparison would you suggest instead of > char-by-char? > > The one which requires knowledge of the underlying > scheme. Interesting. So you expect every Atom client to know the comparison rules of every possible URI scheme? Heck, as Sam pointed out in http://www.intertwingly.net/blog/2004/07/31/URI-Equivalence Java & C# don't even agree on how to compare HTTP URIs let alone arbitrary ones from exotic schemes. Allowing anything besides char-by-char comparison is a recipe for poor interoperability. The XML namespaces recommendation specifies character by character comparison of namespace URIs for a reason. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Fri Aug 20 05:49:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01036 for ; Fri, 20 Aug 2004 05:49:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K9dNk4036488; Fri, 20 Aug 2004 02:39:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K9dNHd036486; Fri, 20 Aug 2004 02:39:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K9dM9j036368 for ; Fri, 20 Aug 2004 02:39:22 -0700 (PDT) (envelope-from grayrest@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so255199rnl for ; Fri, 20 Aug 2004 02:39:17 -0700 (PDT) Received: by 10.38.164.57 with SMTP id m57mr728612rne; Fri, 20 Aug 2004 02:39:16 -0700 (PDT) Received: by 10.38.70.69 with HTTP; Fri, 20 Aug 2004 02:39:16 -0700 (PDT) Message-ID: <476b71e80408200239506dc643@mail.gmail.com> Date: Fri, 20 Aug 2004 05:39:16 -0400 From: grayrest Reply-To: grayrest To: Mark Nottingham Subject: Re: PaceIdConstruct Cc: Atom WG In-Reply-To: <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 20 Aug 2004 01:44:07 -0700, Mark Nottingham wrote: > > If the identified resource is served dynamically, the content of an > > Identification construct MUST be created only once and then stored > > along with the resource. The content of an Identification construct > > MUST NOT be created dynamically. > > "Dynamic" isn't a good term to use in conjunction with the Web; it's > not precisely defined and can be very misleading. Beyond that, I'm > having difficulty parsing this; can you explain? Explanation by example: As a feed implementor for the popular http://example.com, I'm storing Atom entries in my relational database. It would "waste disk space" to store URIs, so when a feed is requested, I generate the required id by taking a url (http://example.com/atom/examplefeed/) and sticking the primary key for each entry onto the end (http://example.com/atomid/examplefeed/132). This is fine, as I control example.com and the PK for entries is guaranteed by my database to be unique. This is fine until the boss decides we need to be running Oracle rather than SQLite. Because I'm lazy (ah, the programmer's virtue) and I've already written an implementation, I'm going to do as little work as possible. I'm certainly not going to re-read the spec and note that I'll have to make sure my id stays the same and it's been a couple years since I originally wrote the code. I'll just dump the database (without PK, as Oracle can generate those) and change my database connection string. Suddenly the UID for the feed changes, since the PK for the new database is different. Chaos ensues and whatnot. The example above is fairly contrived, but I can imagine a number of similar examples (e.g. my company gets bought, we change our domain) where the original author intended a value to be invariant but failed to note it and someone else changes it. The wording is intended to prevent programming errors of this sort by prodding developers to waste storage space by storing the original generated id. From owner-atom-syntax@mail.imc.org Fri Aug 20 05:49:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01071 for ; Fri, 20 Aug 2004 05:49:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K9crht035898; Fri, 20 Aug 2004 02:38:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K9crI7035897; Fri, 20 Aug 2004 02:38:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K9cqVG035882 for ; Fri, 20 Aug 2004 02:38:52 -0700 (PDT) (envelope-from grayrest@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so213881rnl for ; Fri, 20 Aug 2004 02:38:52 -0700 (PDT) Received: by 10.38.96.34 with SMTP id t34mr685327rnb; Fri, 20 Aug 2004 02:38:52 -0700 (PDT) Received: by 10.38.70.69 with HTTP; Fri, 20 Aug 2004 02:38:52 -0700 (PDT) Message-ID: <476b71e80408200238193aaef5@mail.gmail.com> Date: Fri, 20 Aug 2004 05:38:52 -0400 From: grayrest Reply-To: grayrest To: Mark Nottingham Subject: Re: PaceIdConstruct Cc: Atom WG In-Reply-To: <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 20 Aug 2004 01:44:07 -0700, Mark Nottingham wrote: > > If the identified resource is served dynamically, the content of an > > Identification construct MUST be created only once and then stored > > along with the resource. The content of an Identification construct > > MUST NOT be created dynamically. > > "Dynamic" isn't a good term to use in conjunction with the Web; it's > not precisely defined and can be very misleading. Beyond that, I'm > having difficulty parsing this; can you explain? Explanation by example: As a feed implementor for the popular http://example.com, I'm storing Atom entries in my relational database. It would "waste disk space" to store URIs, so when a feed is requested, I generate the required id by taking a url (http://example.com/atom/examplefeed/) and sticking the primary key for each entry onto the end (http://example.com/atomid/examplefeed/132). This is fine, as I control example.com and the PK for entries is guaranteed by my database to be unique. This is fine until the boss decides we need to be running Oracle rather than SQLite. Because I'm lazy (ah, the programmer's virtue) and I've already written an implementation, I'm going to do as little work as possible. I'm certainly not going to re-read the spec and note that I'll have to make sure my id stays the same and it's been a couple years since I originally wrote the code. I'll just dump the database (without PK, as Oracle can generate those) and change my database connection string. Suddenly the UID for the feed changes, since the PK for the new database is different. Chaos ensues and whatnot. The example above is fairly contrived, but I can imagine a number of similar examples (e.g. my company gets bought, we change our domain) where the original author intended a value to be invariant but failed to note it and someone else changes it. The wording is intended to prevent programming errors of this sort by prodding developers to waste storage space by storing the original generated id. From owner-atom-syntax@mail.imc.org Fri Aug 20 06:06:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01745 for ; Fri, 20 Aug 2004 06:06:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K9lXfv039948; Fri, 20 Aug 2004 02:47:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K9lXog039946; Fri, 20 Aug 2004 02:47:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7K9lWLN039895 for ; Fri, 20 Aug 2004 02:47:33 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 29588 messnum 1957740 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 20 Aug 2004 09:47:27 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85) by mail10.svc.cra.dublin.eircom.net (qp 29588) with SMTP; 20 Aug 2004 09:47:27 -0000 Message-ID: <4125C8AC.70406@dehora.net> Date: Fri, 20 Aug 2004 10:47:24 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> In-Reply-To: <4125B244.1090006@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > The one which requires knowledge of the underlying scheme. Since in that > case you are actually comparing URIs, not just the bytes that created > the URI in which case you have used a simple string instead. > > Mark Pilgrim does a better job than me: > > Here's a distinction that might be useful. For Atom the requirement is not that we have URIs for IDs, but that we have high quality IDs that are reasonably cheap to mint in a decentralized way. Specifying URIs is a means to that end. More precisely we're telling people we want them to reuse URI generators as ID generators. So what we're saying in the document is something like this: "Creation: You must use URI generators to *create* these keys - we're insisting you do that because URI generators are the cheapest way we know to mint stable IDs in a fairly simple and fairly decentralised way. Comparison: Because IDs are just keys and because URI comparisons are scheme specific you must *compare* character by character - we're insisting you do that since we think it will be the most effective approach for you to make good matches against the keys." cheers Bill cheers bill From owner-atom-syntax@mail.imc.org Fri Aug 20 07:32:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05761 for ; Fri, 20 Aug 2004 07:32:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KBFgVj075849; Fri, 20 Aug 2004 04:15:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KBFgpj075848; Fri, 20 Aug 2004 04:15:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KBFfo3075837 for ; Fri, 20 Aug 2004 04:15:41 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7KBHSTA011312; Fri, 20 Aug 2004 07:17:28 -0400 Message-ID: <4125DD58.5050900@intertwingly.net> Date: Fri, 20 Aug 2004 07:15:36 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> <412518D4.6070809@intertwingly.net> <4125AFC3.2090101@annevankesteren.nl> In-Reply-To: <4125AFC3.2090101@annevankesteren.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Anne van Kesteren wrote: > >> I also made a change (removed an invalid example) based on feedback >> from Anne van Kesteren [1]. > > I still see that invalid URI. Actually, I see a lot of invalid URIs: > > # If the entity eacute has been defined to be é, the atom:id elements > # below all contain the same URI reference, http://example.org/rosé. > # > # * http://example.org/rosé > # * http://example.org/rosé > # * http://example.org/rosé > # * http://example.org/rosé > # * http://example.org/rosé > > After the XML parser has done it's job, these are all invalid URIs, but > valid IRIs. > > I suggest that you remove that set of examples. Done. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Aug 20 07:40:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06113 for ; Fri, 20 Aug 2004 07:40:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KBWVYV082653; Fri, 20 Aug 2004 04:32:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KBWUi5082651; Fri, 20 Aug 2004 04:32:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KBWUn7082639 for ; Fri, 20 Aug 2004 04:32:30 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7KBYMd2012420; Fri, 20 Aug 2004 07:34:23 -0400 Message-ID: <4125E14F.9050208@intertwingly.net> Date: Fri, 20 Aug 2004 07:32:31 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: Atom WG Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> In-Reply-To: <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Mark Nottingham wrote: > > Hi Sam, > > Looks good overall. A few questions and editorial notes; > >> An Identification construct is an element whose content identifies the >> parent element of the construct. Its content MUST be a URI, subject to >> the following rules: >> • It conveys a permanent, universally unique identifier for its parent >> element > > This is redundant, considering the text above. OK, changed to: An Identification construct is an element whose content conveys a permanent, universally unique identifier the parent element of the construct. Its content MUST be a URI, subject to the following rules: >> • It MUST be universally unique, which means that it must be unique >> both at the time of creation and in the future. >> • It MUST NOT change over time, even if the parent feed or entry >> element is relocated, migrated, syndicated, republished, exported or >> imported. > > Is this a closed list, or are these examples? It may be good to make it > something like "...is changed (e.g., ...)" It is not a closed list, but I think the insertion of the word "changed" would be confusing... as the list is really realocated (with or without change), migrated (with or without change)... >> • atom:id MUST NOT be a relative URI (see "absoluteURI" in RFC-2369, >> section 3) > > RFC2396? 2369bis and IRI are not yet approved. > It's likely I'll need to rewrite this for style, but I think the content > is sound. Regarding the examples, I'm not crazy about putting so many in > the middle of the draft, especially as a list; they'll tend to get in > the way of the other content. A few possible ways around this (not > mutually exclusive): > - incorporate a variety of id's into the main example(s) > - collapse them into prose rather than a list > - add an appendix > - put them in an implementer's guide > Thoughts? Overall, I personally think the current The Atom Syndication Format is lacking in examples. These examples were lifted directly from the Namespaces in XML 1.1 document. Clearly, this is an area where there is signficant confusion. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Aug 20 08:19:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08110 for ; Fri, 20 Aug 2004 08:19:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KC5oQR096165; Fri, 20 Aug 2004 05:05:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KC5ojK096164; Fri, 20 Aug 2004 05:05:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KC5nc6096144; Fri, 20 Aug 2004 05:05:49 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7KC7gYV014221; Fri, 20 Aug 2004 08:07:42 -0400 Message-ID: <4125E91D.40602@intertwingly.net> Date: Fri, 20 Aug 2004 08:05:49 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: PaceDateElement posed (was: PaceDateUpdated posted) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > For example, the two proposals so far (UpdatedAsChosenByThePoster and > SubjectiveBasedOnContent) can exist together with no problem, or could > each be the only date in an entry. Other combinations might not work > together well. Actually, there are three proposals so far, I posted PaceDateElement before either of those two were posted. In fact, it doesn't make sense to combine it with either of those paces, as currently stated: PaceDateElement and PaceDateUpdated are similar enough that I am willing to support either - as long as they are mutually exclusive. PaceDateElement and PaceDatesubjective are conceptually compatible, but they chose the same name for the element name. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Aug 20 08:21:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08165 for ; Fri, 20 Aug 2004 08:21:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KC9ALD097589; Fri, 20 Aug 2004 05:09:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KC9ALh097588; Fri, 20 Aug 2004 05:09:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KC99YF097541 for ; Fri, 20 Aug 2004 05:09:09 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so1555rnk for ; Fri, 20 Aug 2004 05:09:03 -0700 (PDT) Received: by 10.38.22.53 with SMTP id 53mr29325rnv; Fri, 20 Aug 2004 05:09:03 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Fri, 20 Aug 2004 05:09:03 -0700 (PDT) Message-ID: <14be96d3040820050943bfbbb0@mail.gmail.com> Date: Fri, 20 Aug 2004 08:09:03 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Julian Reschke Subject: Re: ID wording Cc: Anne van Kesteren , Atom WG In-Reply-To: <4125B40B.3060505@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 20 Aug 2004 10:19:23 +0200, Julian Reschke wrote: > > > > So, unless Atom requires one or several specific schemes, how is a > generic recipient supposed to do that comparison? > > BTW: I disagree with Mark's suggestion (or with the statement that there > is consensus for) requiring publishers to canonicalize. As far as I can > tell, there's still an ongoing debate over it. Please note that that article was correct when it was submitted, a few hours after this on-list announcement: http://www.imc.org/atom-syntax/mail-archive/msg08317.html Since then, it seems that the consensus has been ignored by a handful of people who apparently couldn't be bothered to keep up with the list during the weeks -- weeks! -- that we were discussing the issue, nor could they be bothered to show up for a vote when a vote was called by the working group chair. Decisions are made by those who show up. As far as I'm concerned, this issue was settled on August 5, by the overwhelming margin of 11.8 to 0 to -7. atom:id is a canonical URI of no particular scheme. Let's move on. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Fri Aug 20 08:28:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09053 for ; Fri, 20 Aug 2004 08:28:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KCFWhT000527; Fri, 20 Aug 2004 05:15:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KCFWiv000526; Fri, 20 Aug 2004 05:15:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KCFVsI000516 for ; Fri, 20 Aug 2004 05:15:31 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7KCHJct014829; Fri, 20 Aug 2004 08:17:19 -0400 Message-ID: <4125EB5F.3010503@intertwingly.net> Date: Fri, 20 Aug 2004 08:15:27 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Pier Fumagalli , Atom Syntax Subject: Re: Syndication of updates and deletions of content References: <9C38CA5A-F23B-11D8-B4D3-000A95984AEA@betaversion.org> <412560AD.3030700@franklinmint.fm> In-Reply-To: <412560AD.3030700@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > If you really, really need to track that resource, we have no > established practice to draw on. So you (and the market in general) will > have to figure out an extension for that. Sorry! The problem with an extension element within an atom:entry is that atom:entry elements may have required children that are may not be available or make sense in the context of a deleted entry. An alternate approach: the current structure of a feed is a head element followed by a series of entries. What if there were a single, optional, element at the end, thus: ... ... ... It seems to me that such a proposal would be fairly orthogonal to the rest of the syndication uses, so would have very little, if any impact. Those that wish to provide this information, could, and those that can make use of such information would be encouraged to do so. Of course, sites like feedster might want to retain the original data, but even there, removing or graying out the link might make sense. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Aug 20 08:49:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10094 for ; Fri, 20 Aug 2004 08:49:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KCXnXo008375; Fri, 20 Aug 2004 05:33:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KCXnuQ008374; Fri, 20 Aug 2004 05:33:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KCXlbN008298 for ; Fri, 20 Aug 2004 05:33:48 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 10536 invoked by uid 65534); 20 Aug 2004 12:33:39 -0000 Received: from p50824C99.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.76.153) by mail.gmx.net (mp025) with SMTP; 20 Aug 2004 14:33:39 +0200 X-Authenticated: #1915285 Message-ID: <4125EFA2.3050209@gmx.de> Date: Fri, 20 Aug 2004 14:33:38 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Anne van Kesteren , Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <14be96d3040820050943bfbbb0@mail.gmail.com> In-Reply-To: <14be96d3040820050943bfbbb0@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: >>BTW: I disagree with Mark's suggestion (or with the statement that there >>is consensus for) requiring publishers to canonicalize. As far as I can >>tell, there's still an ongoing debate over it. > > > Please note that that article was correct when it was submitted, a few > hours after this on-list announcement: > > http://www.imc.org/atom-syntax/mail-archive/msg08317.html > > Since then, it seems that the consensus has been ignored by a handful > of people who apparently couldn't be bothered to keep up with the list > during the weeks -- weeks! -- that we were discussing the issue, nor > could they be bothered to show up for a vote when a vote was called by > the working group chair. Believe it or not, things like this happen. For instance, because people are on vacation. As far as I can tell, that survey lasted exactly one day (the version history for the pace indicates a creation date of August 5!), so how can it claim to reflect the WG's consensus in any way? I remember multiple mails that have been asking for the rational for the "canonical" requirement; and as far as I can tell, I haven't seen a convincing explanation. In case I missed it please point me to it. > Decisions are made by those who show up. As far as I'm concerned, > this issue was settled on August 5, by the overwhelming margin of 11.8 > to 0 to -7. atom:id is a canonical URI of no particular scheme. > Let's move on. Sorry, "rough consensus" doesn't mean having a quick vote and then telling people who raise objections to be silent. A survey is a *tool* that is supposed to detect consensus. If, afterwards, it turns out that there is indeed no consensus of all parts, then you should respect that. So again: what's the motivation for "canonical"? People are supposed to store the identifiers faithfully (as strings) and compare them char-by-char, and that should be it. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 20 09:12:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11397 for ; Fri, 20 Aug 2004 09:12:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KD32Qc015787; Fri, 20 Aug 2004 06:03:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KD32Cg015786; Fri, 20 Aug 2004 06:03:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KD312T015769 for ; Fri, 20 Aug 2004 06:03:01 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so3027rnk for ; Fri, 20 Aug 2004 06:02:55 -0700 (PDT) Received: by 10.38.22.53 with SMTP id 53mr43585rnv; Fri, 20 Aug 2004 06:02:55 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Fri, 20 Aug 2004 06:02:55 -0700 (PDT) Message-ID: <14be96d304082006027d87f69b@mail.gmail.com> Date: Fri, 20 Aug 2004 09:02:55 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Julian Reschke Subject: Re: ID wording Cc: Anne van Kesteren , Atom WG In-Reply-To: <4125EFA2.3050209@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <14be96d3040820050943bfbbb0@mail.gmail.com> <4125EFA2.3050209@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 20 Aug 2004 14:33:38 +0200, Julian Reschke wrote: > I remember multiple mails that have been asking for the rational for the > "canonical" requirement; and as far as I can tell, I haven't seen a > convincing explanation. In case I missed it please point me to it. http://www.xml.com/pub/a/2004/08/18/pilgrim.html > Sorry, "rough consensus" doesn't mean having a quick vote and then > telling people who raise objections to be silent. The quick vote exposed the fact that we already had overwhelming consensus. Which we still do, I might add; two weeks later, the wiki vote stands at 11.8 to 4 to -11. How long were you planning on using the vacation excuse? > A survey is a *tool* that is supposed to detect consensus. And it did a bang-up job. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Fri Aug 20 09:33:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12314 for ; Fri, 20 Aug 2004 09:33:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KDJXXs018644; Fri, 20 Aug 2004 06:19:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KDJXwj018643; Fri, 20 Aug 2004 06:19:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KDJVx8018629 for ; Fri, 20 Aug 2004 06:19:32 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 6351 invoked by uid 65534); 20 Aug 2004 13:19:28 -0000 Received: from p50824C99.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.76.153) by mail.gmx.net (mp014) with SMTP; 20 Aug 2004 15:19:28 +0200 X-Authenticated: #1915285 Message-ID: <4125FA57.7040602@gmx.de> Date: Fri, 20 Aug 2004 15:19:19 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <14be96d3040820050943bfbbb0@mail.gmail.com> <4125EFA2.3050209@gmx.de> <14be96d304082006027d87f69b@mail.gmail.com> In-Reply-To: <14be96d304082006027d87f69b@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > The quick vote exposed the fact that we already had overwhelming > consensus. Which we still do, I might add; two weeks later, the wiki > vote stands at 11.8 to 4 to -11. How long were you planning on using > the vacation excuse? I'm not sure how relevant that Wiki is right now after results had already been posted. Just to make sure, I just added my comment there es well. >>A survey is a *tool* that is supposed to detect consensus. > > > And it did a bang-up job. So how about getting back to the question I asked: "what's the rational for requiring the canonical form?". I assume you can answer that if you're so convinced about it... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 20 09:40:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12658 for ; Fri, 20 Aug 2004 09:40:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KDVAbZ020369; Fri, 20 Aug 2004 06:31:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KDVAxa020367; Fri, 20 Aug 2004 06:31:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KDV9hw020335; Fri, 20 Aug 2004 06:31:09 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1By9U2-00075w-Lc; Fri, 20 Aug 2004 13:31:06 +0000 Message-ID: <4125FD1B.6060105@franklinmint.fm> Date: Fri, 20 Aug 2004 09:31:07 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG , Julian Reschke , Mark Pilgrim Subject: Re: ID wording References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > On Fri, 20 Aug 2004 14:33:38 +0200, Julian Reschke > wrote: > >>Sorry, "rough consensus" doesn't mean having a quick vote and then >>telling people who raise objections to be silent. > > The quick vote exposed the fact that we already had overwhelming > consensus. Which we still do The beginning of this thread makes canonicalization a "suggestion". Julian and Mark: do you agree that Paul's email captures consensus? Robert Sayre Paul Hoffman / IMC wrote: > > Greetings again. Thanks for keeping the moratorium on ID discussion. I > thought it would be best to do a sanity check to be sure people were in > agreement on what it seems the consensus so far was. > > - The format for IDs is going to be URIs, not plain strings. > > - IDs must not change over time. > > - Even though the format is a URI, the IDs are not expected to be > dereferencable (although they might be). > > - IDs MUST be compared character-by-character, no case-mapping, no %xx > conversion, and so on. > > - Receiving and gateway systems MUST NOT alter IDs in any way. > > - Because IDs might be dereferenced, and because they must not be > changed, it is a good idea to create them in a canonicalized form. There > is no interoperability issues with this suggestion, so it is just a > suggestion, not a SHOULD-level suggestion. > > Does this match what people feel was the general consensus? From owner-atom-syntax@mail.imc.org Fri Aug 20 09:59:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13730 for ; Fri, 20 Aug 2004 09:59:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KDi38G022455; Fri, 20 Aug 2004 06:44:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KDi2mn022454; Fri, 20 Aug 2004 06:44:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KDi11W022429 for ; Fri, 20 Aug 2004 06:44:02 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 31785 invoked by uid 65534); 20 Aug 2004 13:43:57 -0000 Received: from p50824C99.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.76.153) by mail.gmx.net (mp002) with SMTP; 20 Aug 2004 15:43:57 +0200 X-Authenticated: #1915285 Message-ID: <4126001B.9010300@gmx.de> Date: Fri, 20 Aug 2004 15:43:55 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Paul Hoffman / IMC , Atom WG , Mark Pilgrim Subject: Re: ID wording References: <4125FD1B.6060105@franklinmint.fm> In-Reply-To: <4125FD1B.6060105@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > The beginning of this thread makes canonicalization a "suggestion". > Julian and Mark: do you agree that Paul's email captures consensus? I agree with the summary, but I still don't understand how "- Because IDs might be dereferenced, and because they must not be changed, it is a good idea to create them in a canonicalized form. There is no interoperability issues with this suggestion, so it is just a suggestion, not a SHOULD-level suggestion." is supposed to help. As long as IDs are stored as-is, and they are always compared char-by-char, it doesn't make any difference whatsoever whether they are canonical or not. So at least the rational for that suggestion needs to be enhanced. (yes, I likecanonicalization as well, but if spec says the same thing if we omit that suggestion, we should do that). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 20 10:52:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18117 for ; Fri, 20 Aug 2004 10:52:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KEepbX029876; Fri, 20 Aug 2004 07:40:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KEepXu029875; Fri, 20 Aug 2004 07:40:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bund.com.au (bund.com.au [203.18.243.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KEeoX4029845 for ; Fri, 20 Aug 2004 07:40:51 -0700 (PDT) (envelope-from mjs@beebo.org) Received: from localhost (localhost [127.0.0.1]) by bund.com.au (Postfix) with ESMTP id 4D6447E2F; Sat, 21 Aug 2004 00:40:44 +1000 (EST) Received: from bund.com.au ([127.0.0.1]) by localhost (bund.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15795-05; Sat, 21 Aug 2004 00:40:41 +1000 (EST) Received: from bund.com.au (localhost [127.0.0.1]) by bund.com.au (Postfix) with ESMTP id 33C277D23; Sat, 21 Aug 2004 00:40:41 +1000 (EST) Received: from 217.154.209.180 (SquirrelMail authenticated user mjs); by bund.com.au with HTTP; Fri, 20 Aug 2004 15:40:41 +0100 (BST) Message-ID: <3046.217.154.209.180.1093012841.squirrel@217.154.209.180> Date: Fri, 20 Aug 2004 15:40:41 +0100 (BST) Subject: why is atom:id globally unique? From: "Michael Stillwell" To: atom-syntax@vpnc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at bund.com.au Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Why does atom:id need to be globally unique? Maybe I'm missing something, but I can't imagine any application actually operating under the assumption that atom:ids were globally unique. (If an aggregator did have complete trust in atom:id, I'd be able to publish "updates" to anyone's blog entry.) How is this field expected to be used? Michael From owner-atom-syntax@mail.imc.org Fri Aug 20 11:05:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19073 for ; Fri, 20 Aug 2004 11:05:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KEss3r031753; Fri, 20 Aug 2004 07:54:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KEssN8031752; Fri, 20 Aug 2004 07:54:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KEsr01031746 for ; Fri, 20 Aug 2004 07:54:53 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 44205 invoked by uid 17064); 20 Aug 2004 14:54:56 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.132.249]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 20 Aug 2004 14:54:56 -0000 In-Reply-To: <3046.217.154.209.180.1093012841.squirrel@217.154.209.180> References: <3046.217.154.209.180.1093012841.squirrel@217.154.209.180> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Michael Stillwell From: Henry Story Subject: Re: why is atom:id globally unique? Date: Fri, 20 Aug 2004 16:54:51 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I imagine these could be very useful if you think of moving entries into a peer to peer network environment, where for example everybody could copy everyone's entries. One would then have a completely distributed system where it would be very difficult for anyone to destroy the content of the blog entries. Otherwise it is very helpful if someone writes an entry that is a reply to someone else's entry. If you look at the entry entry.2004-08-13-1632.n3 [1] in n3 notation you can see that it is an entry that was written in reply to the tag:bblfish.net/20040813/1445/blog1#version1 entry of the blog example I have recently developed[2]. In this example I have the entry be in reply to an entry version, which I think captures the reality of replying to an entry better. Further down in the file the location of that id is specified. This allows entries to still refer to what they were in reply to even if a blog by mis-fortune gets reorganized. A fully peer-to-peer environment would just be an extreme example of such reorganization. Henry [1] http://bblfish.net/work/atom-owl/2004-08-12/entry.2004-08-13-1632.n3 [2] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html On 20 Aug 2004, at 16:40, Michael Stillwell wrote: > > Why does atom:id need to be globally unique? Maybe I'm missing > something, but I can't imagine any application actually operating under > the assumption that atom:ids were globally unique. (If an aggregator > did > have complete trust in atom:id, I'd be able to publish "updates" to > anyone's blog entry.) How is this field expected to be used? > > > > > Michael > From owner-atom-syntax@mail.imc.org Fri Aug 20 11:33:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21360 for ; Fri, 20 Aug 2004 11:33:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFO3hV036027; Fri, 20 Aug 2004 08:24:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KFO3Bp036026; Fri, 20 Aug 2004 08:24:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bund.com.au (bund.com.au [203.18.243.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFO2Wl036020 for ; Fri, 20 Aug 2004 08:24:02 -0700 (PDT) (envelope-from mjs@beebo.org) Received: from localhost (localhost [127.0.0.1]) by bund.com.au (Postfix) with ESMTP id 1CA947E21; Sat, 21 Aug 2004 01:24:04 +1000 (EST) Received: from bund.com.au ([127.0.0.1]) by localhost (bund.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17421-05; Sat, 21 Aug 2004 01:24:01 +1000 (EST) Received: from bund.com.au (localhost [127.0.0.1]) by bund.com.au (Postfix) with ESMTP id 099C07D23; Sat, 21 Aug 2004 01:24:01 +1000 (EST) Received: from 217.154.209.180 (SquirrelMail authenticated user mjs); by bund.com.au with HTTP; Fri, 20 Aug 2004 16:24:01 +0100 (BST) Message-ID: <3853.217.154.209.180.1093015441.squirrel@217.154.209.180> In-Reply-To: References: <3046.217.154.209.180.1093012841.squirrel@217.154.209.180> Date: Fri, 20 Aug 2004 16:24:01 +0100 (BST) Subject: Re: why is atom:id globally unique? From: "Michael Stillwell" To: "Henry Story" Cc: "Atom Syntax" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at bund.com.au Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Henry Story said: > I imagine these could be very useful if you think of moving entries > into a peer to peer network environment, where for example everybody > could copy everyone's entries. One would then have a completely > distributed system where it would be very difficult for anyone to > destroy the content of the blog entries. I wasn't thinking of a situation like this. I was thinking more of a case where a service (technorati?) has a database of all the blog entries in the world, where the primary key of each entry is atom:id, and this is the only means of identifying entries. If this is the case then the database can easily be poisoned by a feed pretending to be an "update." Because of this, the service would need to use something like $FEED_URL + atom:id as the primary key--in which case atom:id only needs to be feed-unique, not globally unique. (Desktop aggregators would have the same problem, though it wouldn't be quite so acute.) --M. -- http://beebo.org From owner-atom-syntax@mail.imc.org Fri Aug 20 11:35:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21638 for ; Fri, 20 Aug 2004 11:35:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFJQ69035431; Fri, 20 Aug 2004 08:19:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KFJQCh035430; Fri, 20 Aug 2004 08:19:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KFJPoT035413 for ; Fri, 20 Aug 2004 08:19:25 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040820151923.74310.qmail@web41215.mail.yahoo.com> Received: from [67.168.130.167] by web41215.mail.yahoo.com via HTTP; Fri, 20 Aug 2004 08:19:23 PDT Date: Fri, 20 Aug 2004 08:19:23 -0700 (PDT) From: Dare Obasanjo Subject: Re: why is atom:id globally unique? To: Michael Stillwell , atom-syntax@vpnc.org In-Reply-To: <3046.217.154.209.180.1093012841.squirrel@217.154.209.180> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Michael Stillwell wrote: > > Why does atom:id need to be globally unique? Maybe > I'm missing > something, but I can't imagine any application > actually operating under > the assumption that atom:ids were globally unique. > (If an aggregator did > have complete trust in atom:id, I'd be able to > publish "updates" to > anyone's blog entry.) How is this field expected to > be used? Aggregators are the primary customers for a globally unique ID. See the post at http://www.imc.org/atom-syntax/mail-archive/msg07874.html which describes some of the problems RSS has because of its lack of globally unique IDs. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Aug 20 11:52:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23181 for ; Fri, 20 Aug 2004 11:52:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFgY1B038729; Fri, 20 Aug 2004 08:42:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KFgYUe038728; Fri, 20 Aug 2004 08:42:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFgX9M038711 for ; Fri, 20 Aug 2004 08:42:33 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id IAA08433 for ; Fri, 20 Aug 2004 08:42:31 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id IAA05390 for ; Fri, 20 Aug 2004 08:42:31 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Fri, 20 Aug 2004 08:42:30 -0700 Received: from adsl-64-166-133-245.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7KFgTlB029055 for ; Fri, 20 Aug 2004 08:42:29 -0700 (PDT) Date: Fri, 20 Aug 2004 08:42:30 -0700 From: Walter Underwood To: Atom WG Subject: Re: ID wording Message-ID: In-Reply-To: <4125B40B.3060505@gmx.de> References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Friday, August 20, 2004 10:19 AM +0200 Julian Reschke wrote: > > As a matter of fact, XML-NS is using URIs for exactly the same purpose > (identification and disambiguation), and guess what comparison method > has been selected? This is not the same as Atom. In XML-NS, this does not introduce two ways to handle URIs, because XML-NS does not specify linking. In Atom, this does introduce two ways to handle URIs, one way for URIs as IDs and one way for URIs as hrefs. As I said yesterday, we require apples (URIs), then require that they are handled as oranges (strings). wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 20 12:03:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23765 for ; Fri, 20 Aug 2004 12:03:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFnxRh040089; Fri, 20 Aug 2004 08:49:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KFnx8r040088; Fri, 20 Aug 2004 08:49:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bund.com.au (bund.com.au [203.18.243.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFnwQk040082 for ; Fri, 20 Aug 2004 08:49:58 -0700 (PDT) (envelope-from mjs@beebo.org) Received: from localhost (localhost [127.0.0.1]) by bund.com.au (Postfix) with ESMTP id 254DB7E2F; Sat, 21 Aug 2004 01:50:00 +1000 (EST) Received: from bund.com.au ([127.0.0.1]) by localhost (bund.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18221-05; Sat, 21 Aug 2004 01:49:56 +1000 (EST) Received: from bund.com.au (localhost [127.0.0.1]) by bund.com.au (Postfix) with ESMTP id E42457E21; Sat, 21 Aug 2004 01:49:56 +1000 (EST) Received: from 217.154.209.180 (SquirrelMail authenticated user mjs); by bund.com.au with HTTP; Fri, 20 Aug 2004 16:49:56 +0100 (BST) Message-ID: <4488.217.154.209.180.1093016996.squirrel@217.154.209.180> In-Reply-To: <20040820151923.74310.qmail@web41215.mail.yahoo.com> References: <3046.217.154.209.180.1093012841.squirrel@217.154.209.180> <20040820151923.74310.qmail@web41215.mail.yahoo.com> Date: Fri, 20 Aug 2004 16:49:56 +0100 (BST) Subject: Re: why is atom:id globally unique? From: "Michael Stillwell" To: "Dare Obasanjo" Cc: atom-syntax@vpnc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at bund.com.au Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dare Obasanjo said: > Aggregators are the primary customers for a globally > unique ID. See the post at > http://www.imc.org/atom-syntax/mail-archive/msg07874.html > which describes some of the problems RSS has because > of its lack of globally unique IDs. Thanks for the link. What does an aggregator do if I publish a feed and you publish a feed, and both contain an entry with the same atom:id, but with entirely different content? If the entries really are the same (in the case of (3)) then it doesn't matter. But if they're different you have a problem: which one do you throw away? --M. -- http://beebo.org From owner-atom-syntax@mail.imc.org Fri Aug 20 12:03:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23835 for ; Fri, 20 Aug 2004 12:03:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFmTqr039754; Fri, 20 Aug 2004 08:48:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KFmT5N039753; Fri, 20 Aug 2004 08:48:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KFmSoO039746 for ; Fri, 20 Aug 2004 08:48:28 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 3CA61727D; Fri, 20 Aug 2004 08:48:31 -0700 (PDT) In-Reply-To: <4125E14F.9050208@intertwingly.net> References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> <4125E14F.9050208@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <6237D9DC-F2C0-11D8-B175-000A95BD86C0@mnot.net> Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceIdConstruct Date: Fri, 20 Aug 2004 08:48:30 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7KFmSoO039747 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Aug 20, 2004, at 4:32 AM, Sam Ruby wrote: > >>> • It MUST be universally unique, which means that it must be unique >>> both at the time of creation and in the future. >>> • It MUST NOT change over time, even if the parent feed or entry >>> element is relocated, migrated, syndicated, republished, exported or >>> imported. >> Is this a closed list, or are these examples? It may be good to make >> it something like "...is changed (e.g., ...)" > > It is not a closed list, but I think the insertion of the word > "changed" would be confusing... as the list is really realocated (with > or without change), migrated (with or without change)... Right. I think the point you're getting at is that whatever an ID conceptually identifies doesn't change over any dimension, including time, just like a cool URI, and additionally, the identity isn't affected by changes in location. The list you give is descriptive, which is good to communicate the gist of the requirement, but it doesn't cover everything, and therefore doesn't make a good requirement. How about "...is changed in content or location (e.g., ...)"? >>> • atom:id MUST NOT be a relative URI (see "absoluteURI" in >>> RFC-2369, section 3) >> RFC2396? > > 2369bis and IRI are not yet approved. RFC2369 is "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields." I think you mean to refer to RFC2396, "Uniform Resource Identifiers (URI): Generic Syntax," no? >> It's likely I'll need to rewrite this for style, but I think the >> content is sound. Regarding the examples, I'm not crazy about putting >> so many in the middle of the draft, especially as a list; they'll >> tend to get in the way of the other content. A few possible ways >> around this (not mutually exclusive): >> - incorporate a variety of id's into the main example(s) >> - collapse them into prose rather than a list >> - add an appendix >> - put them in an implementer's guide >> Thoughts? > > Overall, I personally think the current The Atom Syndication Format is > lacking in examples. These examples were lifted directly from the > Namespaces in XML 1.1 document. Clearly, this is an area where there > is signficant confusion. I totally agree that we need more examples; these are just a bit verbose. There's a fine line between effective communication and restating what's already specified elsewhere. Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Aug 20 12:19:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24592 for ; Fri, 20 Aug 2004 12:19:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KG6MBI042202; Fri, 20 Aug 2004 09:06:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KG6M55042201; Fri, 20 Aug 2004 09:06:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KG6Mki042190 for ; Fri, 20 Aug 2004 09:06:22 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 94406 invoked by uid 17064); 20 Aug 2004 16:06:25 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.132.249]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 20 Aug 2004 16:06:25 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <4488.217.154.209.180.1093016996.squirrel@217.154.209.180> References: <3046.217.154.209.180.1093012841.squirrel@217.154.209.180> <20040820151923.74310.qmail@web41215.mail.yahoo.com> <4488.217.154.209.180.1093016996.squirrel@217.154.209.180> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: why is atom:id globally unique? Date: Fri, 20 Aug 2004 18:06:16 +0200 To: Michael Stillwell , Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit That is a good question. Perhaps one should have an extra signature that relates the id with the content and the foaf:Person object. I know nearly nothing about digital signatures, so I'd be interested to hear what someone who knew on this subject had to say. Henry On 20 Aug 2004, at 17:49, Michael Stillwell wrote: > > Dare Obasanjo said: > >> Aggregators are the primary customers for a globally >> unique ID. See the post at >> http://www.imc.org/atom-syntax/mail-archive/msg07874.html >> which describes some of the problems RSS has because >> of its lack of globally unique IDs. > > Thanks for the link. What does an aggregator do if I publish a feed > and > you publish a feed, and both contain an entry with the same atom:id, > but > with entirely different content? If the entries really are the same > (in > the case of (3)) then it doesn't matter. But if they're different you > have a problem: which one do you throw away? > > > > --M. > > -- > http://beebo.org From owner-atom-syntax@mail.imc.org Fri Aug 20 12:25:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24841 for ; Fri, 20 Aug 2004 12:25:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGHx9T043756; Fri, 20 Aug 2004 09:17:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGHxH3043755; Fri, 20 Aug 2004 09:17:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGHwIF043730 for ; Fri, 20 Aug 2004 09:17:58 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA10497 for ; Fri, 20 Aug 2004 09:17:54 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA09545 for ; Fri, 20 Aug 2004 09:17:54 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Fri, 20 Aug 2004 09:17:53 -0700 Received: from adsl-64-166-133-245.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7KGHplB029261 for ; Fri, 20 Aug 2004 09:17:52 -0700 (PDT) Date: Fri, 20 Aug 2004 09:17:53 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Syndication of updates and deletions of content Message-ID: In-Reply-To: <9CF4CE78-F281-11D8-B4D3-000A95984AEA@betaversion.org> References: <9C38CA5A-F23B-11D8-B4D3-000A95984AEA@betaversion.org> <412560AD.3030700@franklinmint.fm> <9CF4CE78-F281-11D8-B4D3-000A95984AEA@betaversion.org> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Friday, August 20, 2004 9:19 AM +0100 Pier Fumagalli wrote: > > Absolutely... I work for a publication company... NOTHING gets ever > "deleted" (ever - ever - ever). This depends on the organization. When I was working with the search for ABCNews.com, they had permission to keep wire stories on their site for two weeks. After two weeks, they were deleted from the site. All the wire stories were deleted (always - always - always). wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 20 12:25:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24859 for ; Fri, 20 Aug 2004 12:25:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGIVu1043827; Fri, 20 Aug 2004 09:18:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGIVip043826; Fri, 20 Aug 2004 09:18:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGIUeq043818 for ; Fri, 20 Aug 2004 09:18:30 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7KGIX53020862 for ; Fri, 20 Aug 2004 10:18:33 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2R002CC6MWY9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 Aug 2004 10:18:33 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2R0058B6MPJ8@mail.sun.net> for atom-syntax@imc.org; Fri, 20 Aug 2004 10:18:26 -0600 (MDT) Date: Fri, 20 Aug 2004 09:18:37 -0700 From: Tim Bray Subject: Re: PaceIdConstruct In-reply-to: <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> To: Mark Nottingham Cc: Sam Ruby , Atom WG Message-id: <979E9CC8-F2C4-11D8-806F-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 20, 2004, at 1:44 AM, Mark Nottingham wrote: > It's likely I'll need to rewrite this for style, but I think the > content is sound. Regarding the examples, I'm not crazy about putting > so many in the middle of the draft, especially as a list; they'll tend > to get in the way of the other content. A few possible ways around > this (not mutually exclusive): > - incorporate a variety of id's into the main example(s) > - collapse them into prose rather than a list > - add an appendix > - put them in an implementer's guide > Thoughts? I'm OK with edits for style (that's why we have editors), and Anne v.K. pointed out that some of the example URIs actually aren't, but on the other hand, I think it's better to err on the side of too many rather than too few examples (too many RFCs and W3C RECs go the other way). So please retain as many as possible. -Tim From owner-atom-syntax@mail.imc.org Fri Aug 20 12:26:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24905 for ; Fri, 20 Aug 2004 12:26:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGJbIb043974; Fri, 20 Aug 2004 09:19:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGJb4L043973; Fri, 20 Aug 2004 09:19:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGJaBl043966 for ; Fri, 20 Aug 2004 09:19:36 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7KGJbil018171 for ; Fri, 20 Aug 2004 10:19:37 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2R002II6OOY9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 Aug 2004 10:19:37 -0600 (MDT) Received: from [192.168.1.3] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2R005906OOJ8@mail.sun.net> for atom-syntax@imc.org; Fri, 20 Aug 2004 10:19:36 -0600 (MDT) Date: Fri, 20 Aug 2004 09:19:48 -0700 From: Tim Bray Subject: Re: PaceIdConstruct In-reply-to: <476b71e80408200238193aaef5@mail.gmail.com> To: grayrest Cc: Mark Nottingham , Atom WG Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> <476b71e80408200238193aaef5@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 20, 2004, at 2:38 AM, grayrest wrote: > The example above is fairly contrived On the evidence I've seen, it happens all the time -Tim From owner-atom-syntax@mail.imc.org Fri Aug 20 12:34:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25287 for ; Fri, 20 Aug 2004 12:34:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGO9WQ044598; Fri, 20 Aug 2004 09:24:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGO9Jj044597; Fri, 20 Aug 2004 09:24:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGO8p6044584 for ; Fri, 20 Aug 2004 09:24:09 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7KGO2vu013528; Fri, 20 Aug 2004 12:24:02 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BNX06958 (AUTH bob@wyman.us); Fri, 20 Aug 2004 12:24:01 -0400 (EDT) Message-Id: <200408201624.BNX06958@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Michael Stillwell'" , Subject: RE: why is atom:id globally unique? Date: Fri, 20 Aug 2004 12:24:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSGxkme5kxi0UNGRPeFyBrNvp8a8AABuwHQ In-Reply-To: <3046.217.154.209.180.1093012841.squirrel@217.154.209.180> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Michael Stillwell wrote: > Why does atom:id need to be globally unique? As Dare points out, the primary motivation is to support the needs of aggregators that require a means to do cross-feed duplicate detection. (i.e. if you publish the same item in multiple feeds, we should be able to recognize the duplication.) Unfortunately, as I've pointed out in an earlier message[1], while the goal is a good one, the mechanism is useless. Given Atom as currently defined, no respectable aggregator could take advantage of the reputed "global uniqueness" of atom:ids. Even if you find precisely the same atom:id in two different feeds, you would only be able to take that as a "hint" that there might be some similarity between two entries. The similarity in global ids could be the result of: 1. A failure to properly understand or implement the spec 2. A configuration error in an otherwise properly implemented system 3. An explicitly malicious action. (i.e. spoofing) Given that any cross-feed, false-positive matches between atom:ids can result in data-loss, implementations should not assume perform such matches. Aggregators should *only* consider atom:ids in single-feed contexts. The only way that we could *trust* that cross-feed ids had any relationship to each other is if we had either: 1. Mechanisms for doing digital signatures. (Something that we *really, really* should have anyway...) 2. Some means by which a-priori trusted statements could be made about common ownership of feeds. (Note: while this might be useful for individual aggregators, you still couldn't trust any statements made by an intermediary aggregator that generated synthetic feeds...) The only really good reason to ensure today that atom:ids are globally unique is in order to anticipate that one day in the future we will, in fact, add mechanisms to Atom that will allow useful cross-feed comparison of atom:ids. This is a good thing. The cost of making atom:id globally unique today is very limited -- even if generating globally unique ids is not immediately useful. The cost of changing the style and culture of id generation in the future might be very, very high... So, do it now. Hopefully, some day it will be useful. bob wyman [1] For my earlier message on spoofing see: http://www.imc.org/atom-syntax/mail-archive/msg08308.html From owner-atom-syntax@mail.imc.org Fri Aug 20 12:42:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25600 for ; Fri, 20 Aug 2004 12:42:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGVlMc045578; Fri, 20 Aug 2004 09:31:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGVlB6045577; Fri, 20 Aug 2004 09:31:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGVlBq045559 for ; Fri, 20 Aug 2004 09:31:47 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA11216 for ; Fri, 20 Aug 2004 09:31:45 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA11253; Fri, 20 Aug 2004 09:31:44 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Fri, 20 Aug 2004 09:31:44 -0700 Received: from adsl-64-166-133-245.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7KGVglB029324; Fri, 20 Aug 2004 09:31:43 -0700 (PDT) Date: Fri, 20 Aug 2004 09:31:43 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Date Pace for Cache Lifetime Message-ID: <843535E176B18E640CD05854@adsl-64-166-133-245.dsl.snfc21.pacbell.net> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Please contact me directly (mailto:wunder@verity.com) if you are interested in a date Pace about HTTP caching and revisit schedules. I'd like to write one based on HTTP Expires. This was discussed a little before the updated/modified flurry. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 20 12:43:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25696 for ; Fri, 20 Aug 2004 12:43:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGYaQn046011; Fri, 20 Aug 2004 09:34:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGYakP046010; Fri, 20 Aug 2004 09:34:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGYatZ046004 for ; Fri, 20 Aug 2004 09:34:36 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 5C35A727D; Fri, 20 Aug 2004 09:34:39 -0700 (PDT) In-Reply-To: <476b71e80408200239506dc643@mail.gmail.com> References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> <476b71e80408200239506dc643@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceIdConstruct Date: Fri, 20 Aug 2004 09:34:38 -0700 To: grayrest , Sam Ruby X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit That's helpful, thanks. We need to tread very carefully here; this language tries to constrain implementation choices, and that's tricky business. E.g., "stored along with the resource" -- what does that mean, precisely? Am I conformant if the ID is in the same database? The same table? The same sector of the disk? WRT "dynamic," is this requirement violated if I can examine a resource and derive the ID from its data? Metadata? Yes, this is a pedantic view, but that's the nature of standards; any wiggle room or ambiguity will be exploited and cause problems. OTOH, if we're too precise, we'll needlessly tie the hands of implementers; e.g., if someone understands and commits to the notion that ids have to be stable over time, why should their hands be tied with a MUST? My gut feeling is that this is implementation advice, not a set of normative requirements. On Aug 20, 2004, at 2:39 AM, grayrest wrote: > On Fri, 20 Aug 2004 01:44:07 -0700, Mark Nottingham > wrote: >>> If the identified resource is served dynamically, the content of an >>> Identification construct MUST be created only once and then stored >>> along with the resource. The content of an Identification construct >>> MUST NOT be created dynamically. >> >> "Dynamic" isn't a good term to use in conjunction with the Web; it's >> not precisely defined and can be very misleading. Beyond that, I'm >> having difficulty parsing this; can you explain? > > Explanation by example: > > As a feed implementor for the popular http://example.com, I'm storing > Atom entries in my relational database. It would "waste disk space" to > store URIs, so when a feed is requested, I generate the required id by > taking a url (http://example.com/atom/examplefeed/) and sticking the > primary key for each entry onto the end > (http://example.com/atomid/examplefeed/132). This is fine, as I > control example.com and the PK for entries is guaranteed by my > database to be unique. > > This is fine until the boss decides we need to be running Oracle > rather than SQLite. Because I'm lazy (ah, the programmer's virtue) and > I've already written an implementation, I'm going to do as little work > as possible. I'm certainly not going to re-read the spec and note that > I'll have to make sure my id stays the same and it's been a couple > years since I originally wrote the code. I'll just dump the database > (without PK, as Oracle can generate those) and change my database > connection string. Suddenly the UID for the feed changes, since the PK > for the new database is different. Chaos ensues and whatnot. > > The example above is fairly contrived, but I can imagine a number of > similar examples (e.g. my company gets bought, we change our domain) > where the original author intended a value to be invariant but failed > to note it and someone else changes it. The wording is intended to > prevent programming errors of this sort by prodding developers to > waste storage space by storing the original generated id. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Aug 20 12:48:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26590 for ; Fri, 20 Aug 2004 12:48:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGcOCj046434; Fri, 20 Aug 2004 09:38:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGcOR4046433; Fri, 20 Aug 2004 09:38:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from journurl.com (69-56-184-50.theplanet.com [69.56.184.50] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGcNha046409 for ; Fri, 20 Aug 2004 09:38:24 -0700 (PDT) (envelope-from roger@agincourtmedia.com) Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Fri, 20 Aug 2004 11:38:15 -0500 From: "Roger B." To: "'Michael Stillwell'" Cc: "'Atom Syntax'" Subject: RE: why is atom:id globally unique? Date: Fri, 20 Aug 2004 11:43:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <3853.217.154.209.180.1093015441.squirrel@217.154.209.180> Thread-Index: AcSGyd+IIsKczL4TS+yINZ0/wdut2AABiWpg Message-ID: <1F5047F1295041379B4745F5FE2E69.MAI@journurl.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I was thinking more of a > case where a service > (technorati?) has a database of all the blog > entries in the world... Michael: That's a valid concern, but there's probably not a lot that Atom 1.0 can do about it. Sadly, atom:id spam (and rss:link/guid spam, for that matter) will be inevitable once the audience reaches critical mass. It won't be a huge problem for users with desktop aggregators, because they have to knowingly subscribe to a feed, and can easily unsub at any time. Server-based aggregators and datastores will be vulnerable, though, and will find themselves struggling with the same stuff that Google and Company have endured for years. The ultimate solution might look a little like a distributed version of DMoz... thousands of small, focused, and trusted aggregators generating synthetic feeds that are in turn picked up by 2006's version of Technorati or Feedster. Instead of letting entries from individual feeds into the database, everything could be forced through intermediate filters. After all, it's a lot easier for one person running a "How To Grow Chiles" aggregator to police fifty individual feeds than it is for a few dozen people at a centralized service to keep an eye on that same fifty out of a pool of millions. -- Roger Benningfield JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Aug 20 12:52:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26859 for ; Fri, 20 Aug 2004 12:52:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGg3pd046974; Fri, 20 Aug 2004 09:42:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGg36s046973; Fri, 20 Aug 2004 09:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGg2uE046954 for ; Fri, 20 Aug 2004 09:42:02 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA11797 for ; Fri, 20 Aug 2004 09:42:00 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA12509 for ; Fri, 20 Aug 2004 09:42:00 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Fri, 20 Aug 2004 09:41:59 -0700 Received: from adsl-64-166-133-245.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7KGfwlB029374 for ; Fri, 20 Aug 2004 09:41:59 -0700 (PDT) Date: Fri, 20 Aug 2004 09:42:00 -0700 From: Walter Underwood To: Atom WG Subject: Re: PaceIdConstruct Message-ID: In-Reply-To: <979E9CC8-F2C4-11D8-806F-000A95A51C9E@sun.com> References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> <979E9CC8-F2C4-11D8-806F-000A95A51C9E@sun.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Friday, August 20, 2004 9:18 AM -0700 Tim Bray wrote: > > ... on the other hand, I think it's better to err on the side of too > many rather than too few examples (too many RFCs and W3C RECs go the > other way). So please retain as many as possible. -Tim +1 People have different learning styles. Some learn from rules, some from examples. An effective spec needs full coverage in both styles. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 20 13:07:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28050 for ; Fri, 20 Aug 2004 13:07:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGuaOC048925; Fri, 20 Aug 2004 09:56:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KGuadZ048924; Fri, 20 Aug 2004 09:56:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KGuZfq048918 for ; Fri, 20 Aug 2004 09:56:35 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 0F91E727D; Fri, 20 Aug 2004 09:56:39 -0700 (PDT) In-Reply-To: <200408201624.BNX06958@ms8.netsolmail.com> References: <200408201624.BNX06958@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Michael Stillwell'" , X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: why is atom:id globally unique? Date: Fri, 20 Aug 2004 09:56:37 -0700 To: X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 My use case for atom:id is detecting changes between items in the same feed, not cross-feed. The security problems Bob points out are very real, and I think it highly unlikely that there will be enough co-ordination between feeds that aren't published by the same entity, or tool support (think about it; how would people use this, day-to-day?) to make this scenario practical. I can see people using heuristics to figure out if feeds are talking about the same thing. I can see people coming up with a separate extension to do the same thing explicitly. I don't see why it's necessary to tie these things to the identity of an entry or feed itself. On Aug 20, 2004, at 9:24 AM, Bob Wyman wrote: > > Michael Stillwell wrote: >> Why does atom:id need to be globally unique? > As Dare points out, the primary motivation is to support the needs > of aggregators that require a means to do cross-feed duplicate > detection. > (i.e. if you publish the same item in multiple feeds, we should be > able to > recognize the duplication.) > Unfortunately, as I've pointed out in an earlier message[1], while > the goal is a good one, the mechanism is useless. Given Atom as > currently > defined, no respectable aggregator could take advantage of the reputed > "global uniqueness" of atom:ids. Even if you find precisely the same > atom:id > in two different feeds, you would only be able to take that as a > "hint" that > there might be some similarity between two entries. The similarity in > global > ids could be the result of: > 1. A failure to properly understand or implement the spec > 2. A configuration error in an otherwise properly implemented system > 3. An explicitly malicious action. (i.e. spoofing) > Given that any cross-feed, false-positive matches between atom:ids > can result in data-loss, implementations should not assume perform such > matches. > Aggregators should *only* consider atom:ids in single-feed contexts. > > The only way that we could *trust* that cross-feed ids had any > relationship to each other is if we had either: > 1. Mechanisms for doing digital signatures. (Something that we > *really, really* should have anyway...) > 2. Some means by which a-priori trusted statements could be made > about common ownership of feeds. (Note: while this might be useful for > individual aggregators, you still couldn't trust any statements made > by an > intermediary aggregator that generated synthetic feeds...) > > The only really good reason to ensure today that atom:ids are > globally unique is in order to anticipate that one day in the future we > will, in fact, add mechanisms to Atom that will allow useful cross-feed > comparison of atom:ids. This is a good thing. The cost of making > atom:id > globally unique today is very limited -- even if generating globally > unique > ids is not immediately useful. The cost of changing the style and > culture of > id generation in the future might be very, very high... So, do it now. > Hopefully, some day it will be useful. > > bob wyman > > > [1] For my earlier message on spoofing see: > http://www.imc.org/atom-syntax/mail-archive/msg08308.html > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Aug 20 13:31:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00406 for ; Fri, 20 Aug 2004 13:31:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KHJ3GC052137; Fri, 20 Aug 2004 10:19:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KHJ3Kl052136; Fri, 20 Aug 2004 10:19:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KHJ2ls052112 for ; Fri, 20 Aug 2004 10:19:02 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040820171900.62750.qmail@web41206.mail.yahoo.com> Received: from [207.46.238.138] by web41206.mail.yahoo.com via HTTP; Fri, 20 Aug 2004 10:19:00 PDT Date: Fri, 20 Aug 2004 10:19:00 -0700 (PDT) From: Dare Obasanjo Subject: Re: why is atom:id globally unique? To: Michael Stillwell Cc: atom-syntax@vpnc.org In-Reply-To: <4488.217.154.209.180.1093016996.squirrel@217.154.209.180> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Michael Stillwell wrote: > > Thanks for the link. What does an aggregator do if > I publish a feed and > you publish a feed, and both contain an entry with > the same atom:id, but > with entirely different content? If the entries > really are the same (in > the case of (3)) then it doesn't matter. But if > they're different you > have a problem: which one do you throw away? The same thing it does if you are subscribed to multiple RSS feeds where the same entry shows up twice (e.g. subscribed to http://blogs.msdn.com & http://blogs.msdn.com/dareobasanjo). No aggregator I know off will discard one entry. However many users have expressed the desire to want to be able to mark items as read if they appear in multiple feeds and are read once. Of course, an implementation may then decide to discard items with the same atom:id as an implementation optimization but in my mind that could lead to problems one of which you've pointed out. This problems rears itself even more when you are subscribed to search feeds like those generated by PubSub.com or Feedster. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Fri Aug 20 13:32:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00471 for ; Fri, 20 Aug 2004 13:32:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KHJVSS052205; Fri, 20 Aug 2004 10:19:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KHJVnD052204; Fri, 20 Aug 2004 10:19:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KHJTvv052183 for ; Fri, 20 Aug 2004 10:19:30 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 29740 invoked by uid 65534); 20 Aug 2004 17:19:27 -0000 Received: from pD9FF00DE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.0.222) by mail.gmx.net (mp024) with SMTP; 20 Aug 2004 19:19:27 +0200 X-Authenticated: #1915285 Message-ID: <4126329D.4020203@gmx.de> Date: Fri, 20 Aug 2004 19:19:25 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.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: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > > --On Friday, August 20, 2004 10:19 AM +0200 Julian Reschke > wrote: > >> >> As a matter of fact, XML-NS is using URIs for exactly the same purpose >> (identification and disambiguation), and guess what comparison method >> has been selected? > > > This is not the same as Atom. In XML-NS, this does not introduce > two ways to handle URIs, because XML-NS does not specify linking. I don't understand that one. XML-NS uses globally unique identifiers using URI syntax. So does Atom. XML-NS namespace URIs may be referenceable. Same for Atom IDs. Where's the difference? > In Atom, this does introduce two ways to handle URIs, one way for > URIs as IDs and one way for URIs as hrefs. > > As I said yesterday, we require apples (URIs), then require that they > are handled as oranges (strings). Because URIs are a very simple and cheap way to produce these strings. Can you suggest an alternative that has the same properties? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 20 13:45:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01374 for ; Fri, 20 Aug 2004 13:45:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KHWJDh053949; Fri, 20 Aug 2004 10:32:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KHWJx7053948; Fri, 20 Aug 2004 10:32:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KHWJQf053939 for ; Fri, 20 Aug 2004 10:32:19 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id KAA14452 for ; Fri, 20 Aug 2004 10:32:17 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id KAA18167 for ; Fri, 20 Aug 2004 10:32:17 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Fri, 20 Aug 2004 10:32:16 -0700 Received: from adsl-64-166-133-245.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7KHWFlB029618 for ; Fri, 20 Aug 2004 10:32:15 -0700 (PDT) Date: Fri, 20 Aug 2004 10:32:17 -0700 From: Walter Underwood To: Atom WG Subject: Re: ID wording Message-ID: <3F8528DD861F868D1145BCA1@adsl-64-166-133-245.dsl.snfc21.pacbell.net> In-Reply-To: <4126329D.4020203@gmx.de> References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <4126329D.4020203@gmx.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Friday, August 20, 2004 7:19 PM +0200 Julian Reschke wrote: >> >> This is not the same as Atom. In XML-NS, this does not introduce >> two ways to handle URIs, because XML-NS does not specify linking. > > I don't understand that one. XML-NS uses globally unique identifiers > using URI syntax. So does Atom. XML-NS namespace URIs may be referenceable. > Same for Atom IDs. > > Where's the difference? Atom also uses URIs which are supposed to be followed (URLs). XML-NS does not. That is the difference. This is not only about IDs, this is about the Atom spec as a coherent whole. How easy is Atom, not how easy are Atom IDs. Also, the "URI is a string" behavior of XML-NS confuses people every day. Maybe every hour, given how widespread XML is. XML-NS might not be a good example of how to do URIs as IDs. > Because URIs are a very simple and cheap way to produce these strings. > Can you suggest an alternative that has the same properties? No. That does not change the fact that Atom has two ways to handle URIs and that the spec is more complicated because of that. I'm not proposing non-URI IDs. I'm saying that a URI should be treated like a URI whether it is an ID or not. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 20 13:51:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01676 for ; Fri, 20 Aug 2004 13:51:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KHgBqh055339; Fri, 20 Aug 2004 10:42:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KHgBVq055338; Fri, 20 Aug 2004 10:42:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp4.intermedia.net (smtp4.intermedia.net [64.78.61.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KHgBtr055324 for ; Fri, 20 Aug 2004 10:42:11 -0700 (PDT) (envelope-from joe.madia@workstate.com) Received: from ehost004.intermedia.net ([206.40.48.177]) by smtp4.intermedia.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Aug 2004 10:39:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: why is atom:id globally unique? Date: Fri, 20 Aug 2004 10:42:10 -0700 Message-ID: Thread-Topic: why is atom:id globally unique? Thread-Index: AcSGxkEzKhrcL2aMQiOYrvthu5j3mQAEbdQg From: "Joe Madia" To: "Michael Stillwell" , X-OriginalArrivalTime: 20 Aug 2004 17:39:15.0543 (UTC) FILETIME=[9CD63E70:01C486DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7KHgBtr055332 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > (If an aggregator did > have complete trust in atom:id, I'd be able to publish "updates" to > anyone's blog entry.) The issue of intentionally forged IDs is an interesting one that I don't think I've seen mentioned before. (Of course, I may have missed any previous discussions.) A technical solution to this potential problem would require some sort of strong authentication, which seems well out scope for the time being. Fortunately, the non-technical solution is pretty simple: identify any such feeds engaging in ID spam and unsubscribe. I'd be curious to hear the opinions of any aggregator authors about how much trouble an attack like this could cause to their applications out in the wild today. Would an intentionally forged ID "bleed" from one feed to another in your existing code base? Joe From owner-atom-syntax@mail.imc.org Fri Aug 20 13:53:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01799 for ; Fri, 20 Aug 2004 13:53:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KHbuQt054775; Fri, 20 Aug 2004 10:37:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KHbuff054772; Fri, 20 Aug 2004 10:37:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KHbtfb054760 for ; Fri, 20 Aug 2004 10:37:55 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 65581 invoked by uid 17064); 20 Aug 2004 17:37:59 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.132.249]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 20 Aug 2004 17:37:59 -0000 In-Reply-To: <20040820171900.62750.qmail@web41206.mail.yahoo.com> References: <20040820171900.62750.qmail@web41206.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Dare Obasanjo From: Henry Story Subject: Re: why is atom:id globally unique? Date: Fri, 20 Aug 2004 19:37:52 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think one should focus in the spec not on what will happen in case of error or fraud, but on the mechanics of a well working system. You have to work within the legal system which is that you are innocent until proven guilty. The structure should be such that security may at any time be added orthogonally. Imagine what a nightmare it would have been if the inventors of tcp/ip had also worried about packet fraud. They designed a system on which security could be layered. We should do the same. In fact we should design this so extensibility is built into the foundation. Henry On 20 Aug 2004, at 19:19, Dare Obasanjo wrote: > > > --- Michael Stillwell wrote: >> >> Thanks for the link. What does an aggregator do if >> I publish a feed and >> you publish a feed, and both contain an entry with >> the same atom:id, but >> with entirely different content? If the entries >> really are the same (in >> the case of (3)) then it doesn't matter. But if >> they're different you >> have a problem: which one do you throw away? > > The same thing it does if you are subscribed to > multiple RSS feeds where the same entry shows up twice > (e.g. subscribed to http://blogs.msdn.com & > http://blogs.msdn.com/dareobasanjo). No aggregator I > know off will discard one entry. However many users > have expressed the desire to want to be able to mark > items as read if they appear in multiple feeds and are > read once. > > Of course, an implementation may then decide to > discard items with the same atom:id as an > implementation optimization but in my mind that could > lead to problems one of which you've pointed out. > > This problems rears itself even more when you are > subscribed to search feeds like those generated by > PubSub.com or Feedster. > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 > No matter how well it would perform, I will never construct any sort > of machinery which is completely indestructible except for one small > and virtually inaccessible vulnerable spot. > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Fri Aug 20 14:14:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03124 for ; Fri, 20 Aug 2004 14:14:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KI6Wp7059930; Fri, 20 Aug 2004 11:06:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KI6WTV059929; Fri, 20 Aug 2004 11:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KI6UU2059808 for ; Fri, 20 Aug 2004 11:06:31 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 29048 invoked by uid 65534); 20 Aug 2004 18:06:29 -0000 Received: from pD9FF00DE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.0.222) by mail.gmx.net (mp017) with SMTP; 20 Aug 2004 20:06:29 +0200 X-Authenticated: #1915285 Message-ID: <41263D9E.2090301@gmx.de> Date: Fri, 20 Aug 2004 20:06:22 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <4126329D.4020203@gmx.de> <3F8528DD861F868D1145BCA1@adsl-64-166-133-245.dsl.snfc21.pacbell.net> In-Reply-To: <3F8528DD861F868D1145BCA1@adsl-64-166-133-245.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > ... > I'm not proposing non-URI IDs. I'm saying that a URI should be > treated like a URI whether it is an ID or not. OK, so can you be a bit more specific about how we're not using the URI as a URI here? Would you prefer a different way to compare two IDs? Which? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 20 14:21:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03564 for ; Fri, 20 Aug 2004 14:21:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KI9aHY060472; Fri, 20 Aug 2004 11:09:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KI9aAK060471; Fri, 20 Aug 2004 11:09:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KI9Za4060450 for ; Fri, 20 Aug 2004 11:09:35 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id LAA16704 for ; Fri, 20 Aug 2004 11:09:34 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id LAA22885 for ; Fri, 20 Aug 2004 11:09:28 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Fri, 20 Aug 2004 11:09:12 -0700 Received: from adsl-64-166-133-245.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7KI9BlB029847 for ; Fri, 20 Aug 2004 11:09:12 -0700 (PDT) Date: Fri, 20 Aug 2004 11:09:13 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: why is atom:id globally unique? Message-ID: <783C9AD2B006456C7D963CA6@adsl-64-166-133-245.dsl.snfc21.pacbell.net> In-Reply-To: References: <20040820171900.62750.qmail@web41206.mail.yahoo.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Friday, August 20, 2004 7:37 PM +0200 Henry Story wrote: > > I think one should focus in the spec not on what will happen in case of > error or fraud, but on the mechanics of a well working system. With the Spam Army out there, hostile feeds are guaranteed to show up. A vulnerable system is probably not a working system. Trusted feeds would be a very clear reason to switch to Atom. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 20 14:38:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04599 for ; Fri, 20 Aug 2004 14:38:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KIRGQA063040; Fri, 20 Aug 2004 11:27:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KIRGGt063039; Fri, 20 Aug 2004 11:27:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KIRGWL063030 for ; Fri, 20 Aug 2004 11:27:16 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1ByE6X-0007nb-Ko; Fri, 20 Aug 2004 18:27:09 +0000 Message-ID: <4126427D.6040306@franklinmint.fm> Date: Fri, 20 Aug 2004 14:27:09 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: bob@wyman.us, "'Michael Stillwell'" , Atom Syntax Subject: Re: why is atom:id globally unique? References: <200408201624.BNX06958@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > +1 > > My use case for atom:id is detecting changes between items in the same > feed, not cross-feed. The security problems Bob points out are very > real, and I think it highly unlikely that there will be enough > co-ordination between feeds that aren't published by the same entity, or > tool support (think about it; how would people use this, day-to-day?) to > make this scenario practical. You don't think it's good enough to solve the "synthetic feed" problem? I'm sick of dealing with duplicate content from, say, Planet Apache. One of my email clients deals with all the CCing on this list by consolidating via Message-ID headers. Seems to work pretty well, but I'm sure it's vulnerable. All of the problems Bob lists will certainly happen, but the solution does not need to be 100% effective to make things suck less. > > I can see people using heuristics to figure out if feeds are talking > about the same thing. I can see people coming up with a separate > extension to do the same thing explicitly. I don't see why it's > necessary to tie these things to the identity of an entry or feed itself. > Why not match on ID first, then start the heuristics? This seems to be an issue for search engines, and not very different from the problems they already face. If a synthetic feed is spewing spam at me... I'll unsubscribe. It'll work great when I'm getting duplicate content from multiple trusted sources. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Aug 20 15:07:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06813 for ; Fri, 20 Aug 2004 15:07:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KIsEBm066926; Fri, 20 Aug 2004 11:54:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KIsEo7066925; Fri, 20 Aug 2004 11:54:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KIsBOj066916; Fri, 20 Aug 2004 11:54:12 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <20040820171900.62750.qmail@web41206.mail.yahoo.com> Date: Fri, 20 Aug 2004 11:53:52 -0700 To: Henry Story , Atom Syntax From: Paul Hoffman / IMC Subject: Re: why is atom:id globally unique? Cc: Dare Obasanjo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:37 PM +0200 8/20/04, Henry Story wrote: >I think one should focus in the spec not on what will happen in case >of error or fraud, >but on the mechanics of a well working system. You have to work >within the legal system which is that you are innocent until proven >guilty. ARMCHAIR LAWYER ALERT! We are talking about a standard that will be used in literally thousands of different legal jurisdictions, with at least that many different definitions of "error", "fraud", "innocent", and "guilty". (Hint: most of those jurisdictions don't use English as their primary language.) We can't fix that; trying to do so is insane. We just shrug and give people a standard that says "MUST this" and "MUST that" and let them decide locally what to do with it. >Imagine what a nightmare it would have been if the inventors of >tcp/ip had also worried about packet fraud. They did. And they were smart enough to label it "out of scope". --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Aug 20 15:26:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08621 for ; Fri, 20 Aug 2004 15:26:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KJEYWq070087; Fri, 20 Aug 2004 12:14:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KJEYvD070086; Fri, 20 Aug 2004 12:14:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KJEYCl070001 for ; Fri, 20 Aug 2004 12:14:34 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 33944 invoked by uid 17064); 20 Aug 2004 19:14:27 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.132.249]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 20 Aug 2004 19:14:27 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040820171900.62750.qmail@web41206.mail.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2444E7D2-F2DD-11D8-BAC6-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: why is atom:id globally unique? Date: Fri, 20 Aug 2004 21:14:21 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 Aug 2004, at 20:53, Paul Hoffman / IMC wrote: > At 7:37 PM +0200 8/20/04, Henry Story wrote: >> I think one should focus in the spec not on what will happen in case >> of error or fraud, >> but on the mechanics of a well working system. You have to work >> within the legal system which is that you are innocent until proven >> guilty. > > ARMCHAIR LAWYER ALERT! > > We are talking about a standard that will be used in literally > thousands of different legal jurisdictions, with at least that many > different definitions of "error", "fraud", "innocent", and "guilty". > (Hint: most of those jurisdictions don't use English as their primary > language.) I know. I live in France where I am told you are guilty until proven innocent. My point was methodological: when developing a system don't spend all your energy imagining up all the ways it could be misused. Concentrate on designing the system flexibly so that security can later be layered properly. In another e-mail I even suggested that one could build a signature from the content, the Agent and the id. The building of such solutions are out of scope, but the architecture has to support the later building of them. > > We can't fix that; trying to do so is insane. We just shrug and give > people a standard that says "MUST this" and "MUST that" and let them > decide locally what to do with it. > >> Imagine what a nightmare it would have been if the inventors of >> tcp/ip had also worried about packet fraud. > > They did. And they were smart enough to label it "out of scope". That is what I was suggesting we do: label it out of scope, but make sure that the basic architecture is not so inflexibly designed as to make it impossible to add later. Hence the importance again of *extensibility*. Henry Story http://bblfish.net/ > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-atom-syntax@mail.imc.org Fri Aug 20 15:31:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08870 for ; Fri, 20 Aug 2004 15:31:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KJNpIe071409; Fri, 20 Aug 2004 12:23:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KJNpVm071408; Fri, 20 Aug 2004 12:23:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KJNoN6071376 for ; Fri, 20 Aug 2004 12:23:50 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id MAA20395 for ; Fri, 20 Aug 2004 12:23:49 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id MAA04752 for ; Fri, 20 Aug 2004 12:23:49 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Fri, 20 Aug 2004 12:23:49 -0700 Received: from adsl-64-166-133-245.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7KJNllB000327 for ; Fri, 20 Aug 2004 12:23:48 -0700 (PDT) Date: Fri, 20 Aug 2004 12:23:49 -0700 From: Walter Underwood To: Atom WG Subject: Re: ID wording Message-ID: <66338E940A2EBC5DCD9FFCFB@adsl-64-166-133-245.dsl.snfc21.pacbell.net> In-Reply-To: <41263D9E.2090301@gmx.de> References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <41263D9E.2090301@gmx.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Friday, August 20, 2004 8:06 PM +0200 Julian Reschke wrote: > Walter Underwood wrote: > >> ... >> I'm not proposing non-URI IDs. I'm saying that a URI should be >> treated like a URI whether it is an ID or not. > > so can you be a bit more specific about how we're not using the URI as a > URI here? Would you prefer a different way to compare two IDs? Which? It is a structured string and we are ignoring the structure. It like comparing two timestamps as strings. They might be the same instant in different timezones, but string comparison won't catch that. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 20 16:18:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11279 for ; Fri, 20 Aug 2004 16:18:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KK40Is077833; Fri, 20 Aug 2004 13:04:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KK40Q2077832; Fri, 20 Aug 2004 13:04:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41211.mail.yahoo.com (web41211.mail.yahoo.com [66.218.93.44]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KK3xZT077805 for ; Fri, 20 Aug 2004 13:03:59 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040820200359.73464.qmail@web41211.mail.yahoo.com> Received: from [131.107.76.30] by web41211.mail.yahoo.com via HTTP; Fri, 20 Aug 2004 13:03:59 PDT Date: Fri, 20 Aug 2004 13:03:59 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID wording To: Walter Underwood , Atom WG In-Reply-To: <66338E940A2EBC5DCD9FFCFB@adsl-64-166-133-245.dsl.snfc21.pacbell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Walter Underwood wrote: > > It is a structured string and we are ignoring the > structure. > It like comparing two timestamps as strings. They > might be > the same instant in different timezones, but string > comparison Instead of complaining why don't you suggest a feasible alternative? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Aug 20 17:10:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14228 for ; Fri, 20 Aug 2004 17:10:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KKuHRp085531; Fri, 20 Aug 2004 13:56:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KKuHfF085530; Fri, 20 Aug 2004 13:56:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KKuGNO085522 for ; Fri, 20 Aug 2004 13:56:16 -0700 (PDT) (envelope-from jfc@datajournal.dj) Received: from [80.125.69.13] (helo=jfc.datajournal.dj) by montage.altserver.com with esmtp (Exim 4.34) id 1ByGQq-0005iw-5Y; Fri, 20 Aug 2004 13:56:16 -0700 Message-Id: <6.1.2.0.2.20040820224132.02521838@mail.datajournal.dj> X-Sender: jfc+datajournal.dj@mail.datajournal.dj X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 20 Aug 2004 22:55:44 +0200 To: Dare Obasanjo , Michael Stillwell From: DJWS Subject: Re: why is atom:id globally unique? Cc: atom-syntax@vpnc.org In-Reply-To: <20040820171900.62750.qmail@web41206.mail.yahoo.com> References: <4488.217.154.209.180.1093016996.squirrel@217.154.209.180> <20040820171900.62750.qmail@web41206.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - vpnc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - datajournal.dj Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 19:19 20/08/2004, Dare Obasanjo wrote: >No aggregator I know off will discard one entry. However many users have >expressed the desire to want to be able to mark items as read if they >appear in multiple feeds and are read once. Let assume we are in a professional real world. The first demand is to get an organized thematic globally unique identification. The need being to organize the presentation to remove the duplicates and to identify the real source and to be able to exchange with it. If this is not provided by a globally unique atom:id, another unique ID must be provided which permits to authenticate the signatoree or request more information. Questions: 1. let call a "guide" a globally unique id with exchange possibility. Can it be confirmed that an atom:guide definition is out of scope? 2. in such a case it should be possible to use externally defined atom:id where the id semantic would have a meaning to those using it as a "guide" and transparent to others. Is this a good place for it? Is there any objection to this? jfc From owner-atom-syntax@mail.imc.org Fri Aug 20 17:34:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15700 for ; Fri, 20 Aug 2004 17:34:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KLNBEW090144; Fri, 20 Aug 2004 14:23:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KLNB5U090143; Fri, 20 Aug 2004 14:23:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7KLNAaH090125 for ; Fri, 20 Aug 2004 14:23:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 43919 messnum 2071095 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 20 Aug 2004 21:23:08 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail09.svc.cra.dublin.eircom.net (qp 43919) with SMTP; 20 Aug 2004 21:23:08 -0000 Message-ID: <41266BB9.8020706@dehora.net> Date: Fri, 20 Aug 2004 22:23:05 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: atom-syntax@vpnc.org Subject: Re: why is atom:id globally unique? References: <200408201624.BNX06958@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > +1 > > My use case for atom:id is detecting changes between items in the same > feed, not cross-feed. 0 My use cases are for both, but primarily the latter. They live outside of the scope of blogging/aggregating tools and the problem is important enough to ensure a generator and process that will emit stable IDs. > The security problems Bob points out are very > real, and I think it highly unlikely that there will be enough > co-ordination between feeds that aren't published by the same entity, or > tool support (think about it; how would people use this, day-to-day?) to > make this scenario practical. The argument above leads to the inevitability of using the http: scheme for id generation - despite the problems others rightly point out, a DPH will find no better bang for the buck. We may coming full circle. [I do this loop roughly every six months in my job.] > I can see people using heuristics to figure out if feeds are talking > about the same thing. I can see people coming up with a separate > extension to do the same thing explicitly. I don't see why it's > necessary to tie these things to the identity of an entry or feed itself. Bob's says they're useless; I would would say they're more useful than not having them. Except in very specific circumstances, dirty searches and composite keys are a last resort. Data quality is out of scope but leverage to enable quality is not. cheers Bill From owner-atom-syntax@mail.imc.org Fri Aug 20 18:08:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17824 for ; Fri, 20 Aug 2004 18:08:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KLxbFH095836; Fri, 20 Aug 2004 14:59:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KLxbnh095835; Fri, 20 Aug 2004 14:59:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KLxacP095813 for ; Fri, 20 Aug 2004 14:59:36 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id OAA27135 for ; Fri, 20 Aug 2004 14:59:36 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id OAA18470 for ; Fri, 20 Aug 2004 14:59:36 -0700 (PDT) Received: from shazam.verity.com (shazam.verity.com [10.3.100.155]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Fri, 20 Aug 2004 14:59:36 -0700 Received: from [192.168.150.112] (shazam.verity.com [10.3.100.155]) by shazam.verity.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I2R003HUMFB4T@shazam.verity.com> for atom-syntax@imc.org; Fri, 20 Aug 2004 14:59:35 -0700 (PDT) Date: Fri, 20 Aug 2004 15:11:11 -0700 From: Walter Underwood Subject: Re: ID wording In-reply-to: To: Atom WG Message-id: <167BB9DC252A3C6BF7154507@diva.verity.com> MIME-version: 1.0 X-Mailer: Mulberry/3.1.5 (Linux/x86) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT I'll try this again, but referencing the wording directly. --On Wednesday, August 18, 2004 01:57:48 PM -0700 "Paul Hoffman / IMC" wrote: > > Greetings again. Thanks for keeping the moratorium on ID discussion. I > thought it would be best to do a sanity check to be sure people were in > agreement on what it seems the consensus so far was. > > - The format for IDs is going to be URIs, not plain strings. This is a change from Tim Bray's declaration of consensus on Aug 5. That was for "canonical URIs", not "URIs". There was one objection, on the grounds that there might be some RDF out there with non-canonical URIs and that those might end up in Atom feeds. We can address those by making URI a MUST and canonical URI a SHOULD, explaining that the SHOULD is only for legacy IDs. We have talked about legacy data with LiveJournal dates, so making exceptions for legacy IDs makes sense, but only if there really are non-canonical URIs IDs in major implementations. If they are not common, make canonical URI a MUST. > - IDs MUST be compared character-by-character, no case-mapping, no %xx > conversion, and so on. This is safe for canonical URIs, though there is no need to forbid fancier comparisons which also work on canonical URIs. If canonical URIs are a SHOULD, then this is a MUST. If they are a MUST, then this is implementation advice for fast compare, but not a MUST for protocol correctness. In short, we MUST have either canonical URIs or char-by-char compares. The former is easier to test and probably more robust. The latter is simple to implement and probably faster (no canonicalization step). Personally, I prefer robustness over premature optimization, but I haven't seen consensus on that. > - Receiving and gateway systems MUST NOT alter IDs in any way. This makes sense for gateways. I don't see how it applies to "receiving systems" whatever they are. Is there something that gateways are supposed to alter? Shouldn't they leave entries unaltered anyway? Perhaps this is a requirement on how entries are stored when they are not in protocol units? Maybe "IDs MUST NOT be altered when stored, transmitted, or recieved". wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Fri Aug 20 19:55:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23676 for ; Fri, 20 Aug 2004 19:55:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KNk2if010502; Fri, 20 Aug 2004 16:46:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7KNk2iR010501; Fri, 20 Aug 2004 16:46:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7KNk1gx010487 for ; Fri, 20 Aug 2004 16:46:02 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7KNk3vw029732; Fri, 20 Aug 2004 19:46:03 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BNY75624 (AUTH bob@wyman.us); Fri, 20 Aug 2004 19:46:02 -0400 (EDT) Message-Id: <200408202346.BNY75624@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" Cc: Subject: RE: why is atom:id globally unique? Date: Fri, 20 Aug 2004 19:46:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSG/kuEqThS65bnQTixRwKk/JFN2AABZXIA In-Reply-To: <41266BB9.8020706@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7KNk2gx010496 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > Bob [Wyman] says they're useless; I would say they're more > useful than not having them. Perhaps a test case would help clarify things. Given the "story" below, how is atom:id useful in this specific cross-feed example? One day, a guy named Farnsworth creates a feed like the following (very abbreviated...) one: Farnsworth GUID1234 Today, I invented 3D television! The folk at "Invention Theft, Inc." use PubSub.com and discover Farnsworth's feed only seconds after it is published since Farnsworth's CMS pings http://xping.pubsub.com/ping . They then create the following feed which, unfortunately, is found by some other blog search or matching service *before* that service finds Farnsworth's earlier entry. (Different services will scan feeds or receive updates in different sequences...) Invention Theft, Inc. GUID1234 Today, I invented 3D television! What should the second blog search engine do when it processes Farnsworth's feed? Should it pass the entry through or should they reject it as an obvious duplicate? If lawyers inspect that database 10 years from now, to whom will they give credit for inventing the 3D television? If atom:id is "useful" in cross-feed situations, it seems logical that it would be useful in a case where two entries are byte-for-byte identical. I continue to believe that atom:id, as currently defined, is useless in cross-feed contexts. Nonetheless, as stated before, I do think that we should require globally unique atom:ids since I think they are cheaply created and *may* be useful in the future. The spec, however, should probably warn against any cross-feed comparison of atom:ids. bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 20 21:29:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28811 for ; Fri, 20 Aug 2004 21:29:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L1GIr6022738; Fri, 20 Aug 2004 18:16:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L1GIOH022737; Fri, 20 Aug 2004 18:16:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7L1GHbR022718 for ; Fri, 20 Aug 2004 18:16:18 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 31292 messnum 5070791 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 21 Aug 2004 01:16:15 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail04.svc.cra.dublin.eircom.net (qp 31292) with SMTP; 21 Aug 2004 01:16:15 -0000 Message-ID: <4126A25B.9030104@dehora.net> Date: Sat, 21 Aug 2004 02:16:11 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@vpnc.org Subject: Re: why is atom:id globally unique? References: <200408202346.BNY75624@ms8.netsolmail.com> In-Reply-To: <200408202346.BNY75624@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bob Wyman wrote: > Bill de hÓra wrote: > >>Bob [Wyman] says they're useless; I would say they're more >>useful than not having them. > > Perhaps a test case would help clarify things. > Given the "story" > below, how is atom:id useful in this specific cross-feed example? > > One day, a guy named Farnsworth creates a feed like the following > (very abbreviated...) one: > > Farnsworth > > GUID1234 > Today, I invented 3D television! > > > > The folk at "Invention Theft, Inc." use PubSub.com and discover > Farnsworth's feed only seconds after it is published since Farnsworth's CMS > pings http://xping.pubsub.com/ping . They then create the following feed > which, unfortunately, is found by some other blog search or matching service > *before* that service finds Farnsworth's earlier entry. (Different services > will scan feeds or receive updates in different sequences...) > > Invention Theft, Inc. > > GUID1234 > Today, I invented 3D television! > > > > What should the second blog search engine do when it processes > Farnsworth's feed? Should it pass the entry through or should they reject it > as an obvious duplicate? If lawyers inspect that database 10 years from now, > to whom will they give credit for inventing the 3D television? What should you do if this third feed arrives: Invention Theft, Inc. GUID1234 Today, I invented 3D television! is it the same as one of the other feeds? How do you *know*? > I continue to believe that atom:id, as currently defined, is useless > in cross-feed contexts. That's funny, I'm finding atom:id useful in cross feed contexts. But I'm not using Atom for blogging in that case. I'm also mandating hierarchal URIs to reduce the chance of clashes - it's not asking much to do this, much less than asking for some kind of a bitwise comparision on content. You've shown one example no doubt derived from real feed data in PubSub; but you haven't show as a result it's a 'useless' mechanism. > Nonetheless, as stated before, I do think that we > should require globally unique atom:ids since I think they are cheaply > created and *may* be useful in the future. They're useful right now. > The spec, however, should > probably warn against any cross-feed comparison of atom:ids. I disagree, that's a data quality issue. All the spec has to do is provide a means to enable data quality. cheers Bill From owner-atom-syntax@mail.imc.org Fri Aug 20 22:12:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00635 for ; Fri, 20 Aug 2004 22:12:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L1wnv9027274; Fri, 20 Aug 2004 18:58:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L1wnnu027273; Fri, 20 Aug 2004 18:58:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L1wn5u027265 for ; Fri, 20 Aug 2004 18:58:49 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7L1wquo027534 for ; Fri, 20 Aug 2004 21:58:53 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BNZ04687 (AUTH bob@wyman.us); Fri, 20 Aug 2004 21:58:52 -0400 (EDT) Message-Id: <200408210158.BNZ04687@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom-Syntax'" Subject: Atom discussed at IPTC Annual General Meeting in Hong Kong, 25-28 June 2004 Date: Fri, 20 Aug 2004 21:59:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSHIm0If7HPwaBxTv+qnciMvZNOUQ== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Atom was discussed at the recent IPTC Standards Groups Annual General Meeting. Some concern was expressed that Atom might be a competitor to NewsML... It would probably make sense for us to put some effort into figuring out how to work better with the IPTC. After all, based on considerable experience in this field, they define the standards that are used by the traditional "news syndicators"... The following notes are taken from the "IPTC Mirror" the IPTC's newsletter.[1] "Some concern was expressed over the news that the Atom group were working with the W3C to adopt Atom as a standard for news content transfer, and this could be considered to be a direct competitor to NewsML. "The Standards Committe chairman told delegates that the matter had been considered during the Management Committee Meeting and the view was that Atom was a Business-to-Consumer model while NewsML was Business-to-Business. However the Management Committee were aware that adoption by W3C could give a standard considerable momentum and were considering approaching the W3C to present NewsML 2 as a news exchange standard." bob wyman [1] See Page 7, column three, upper right of the page in: http://www.iptc.org/download/mirror/IPTCmirror121-print.pdf From owner-atom-syntax@mail.imc.org Fri Aug 20 22:31:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01556 for ; Fri, 20 Aug 2004 22:31:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L2Ln0H030355; Fri, 20 Aug 2004 19:21:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L2Ln7f030354; Fri, 20 Aug 2004 19:21:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L2LlPg030333 for ; Fri, 20 Aug 2004 19:21:47 -0700 (PDT) (envelope-from philmc@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so24267rnl for ; Fri, 20 Aug 2004 19:21:45 -0700 (PDT) Received: by 10.38.99.64 with SMTP id w64mr333703rnb; Fri, 20 Aug 2004 19:21:44 -0700 (PDT) Received: by 10.38.79.61 with HTTP; Fri, 20 Aug 2004 19:21:44 -0700 (PDT) Message-ID: <87de4a204082019211f69dde4@mail.gmail.com> Date: Sat, 21 Aug 2004 12:21:44 +1000 From: Phil McCluskey Reply-To: Phil McCluskey To: bob@wyman.us Subject: Re: why is atom:id globally unique? Cc: "Bill de hÓra" , atom-syntax@vpnc.org In-Reply-To: <200408202346.BNY75624@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408202346.BNY75624@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I continue to believe that atom:id, as currently defined, is useless > in cross-feed contexts. Nonetheless, as stated before, I do think that we > should require globally unique atom:ids since I think they are cheaply > created and *may* be useful in the future. The spec, however, should > probably warn against any cross-feed comparison of atom:ids. > If looked at in isolation, the atom:id is probably not useful, but in the context of both the entry and the link(s), and the uri of the feed I think it could be usefully used by aggregator authors. Where the atom:id, the entry text and the link(s) are common, you could safely assume that the entry has been duplicated across feeds (as in Dare's scenario above), and mark both entries as read when one of them is. I think that's probably more useful behavior for the end user than discarding an entry that has the same id. Where the entries and the atom:ids are identical but the links are different, you could prepend the additional links to both entries as supplementary. Where the the atom:ids and links are identical but the entries are different, it could be possible to thread the additional entry against each original as if they were part of the same conversation. From owner-atom-syntax@mail.imc.org Sat Aug 21 01:05:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07822 for ; Sat, 21 Aug 2004 01:05:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L4owvm050030; Fri, 20 Aug 2004 21:50:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L4owMI050029; Fri, 20 Aug 2004 21:50:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L4ovFv050013 for ; Fri, 20 Aug 2004 21:50:57 -0700 (PDT) (envelope-from wkearney99@hotmail.com) Message-Id: <200408210450.i7L4ovFv050013@above.proper.com> Received: (qmail 15271 invoked from network); 21 Aug 2004 04:51:02 -0000 Received: from xbox.wkearney.com (HELO Chilly) (wkearney@[66.92.145.79]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Aug 2004 04:51:02 -0000 From: "Bill Kearney" To: Subject: RE: Atom discussed at IPTC Annual General Meeting in Hong Kong, 25-28 June 2004 Date: Sat, 21 Aug 2004 00:51:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200408210158.BNZ04687@ms8.netsolmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSHIm0If7HPwaBxTv+qnciMvZNOUQAF/Izw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit All I can say is "and if you thing RDF is verbose..." > -----Original Message----- > Atom was discussed at the recent IPTC Standards Groups > Annual General Meeting. Some concern was expressed that Atom > might be a competitor to NewsML... From owner-atom-syntax@mail.imc.org Sat Aug 21 02:37:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26364 for ; Sat, 21 Aug 2004 02:37:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L6OG9f065606; Fri, 20 Aug 2004 23:24:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L6OGTA065605; Fri, 20 Aug 2004 23:24:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L6ODgT065591 for ; Fri, 20 Aug 2004 23:24:14 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 21 Aug 2004 16:30:58 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 Aug 2004 16:24:05 +1000 Subject: Re: why is atom:id globally unique? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21/8/04 2:56 AM, "Mark Nottingham" wrote: > My use case for atom:id is detecting changes between items in the same > feed, not cross-feed. One of my clients has multiple feeds, one for each section of their site. They also have a feed for the front page of their site. Not every story they post ends up on the front page, just the more interesting ones. Currently, anyone subscribed to the front page feed and one (or more) of the section feeds will be confronted with cross-feed duplicates. Quite tiresome, really, I know because I'm subscribed to all their feeds. e. From owner-atom-syntax@mail.imc.org Sat Aug 21 04:46:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01942 for ; Sat, 21 Aug 2004 04:46:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L8TK89088969; Sat, 21 Aug 2004 01:29:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L8TKcB088968; Sat, 21 Aug 2004 01:29:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7L8TITr088903 for ; Sat, 21 Aug 2004 01:29:19 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 29779 invoked by uid 65534); 21 Aug 2004 08:29:08 -0000 Received: from pD953560F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.86.15) by mail.gmx.net (mp023) with SMTP; 21 Aug 2004 10:29:08 +0200 X-Authenticated: #1915285 Message-ID: <412707CE.3010609@gmx.de> Date: Sat, 21 Aug 2004 10:29:02 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <41263D9E.2090301@gmx.de> <66338E940A2EBC5DCD9FFCFB@adsl-64-166-133-245.dsl.snfc21.pacbell.net> In-Reply-To: <66338E940A2EBC5DCD9FFCFB@adsl-64-166-133-245.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > > --On Friday, August 20, 2004 8:06 PM +0200 Julian Reschke > wrote: > >> Walter Underwood wrote: >> >>> ... >>> I'm not proposing non-URI IDs. I'm saying that a URI should be >>> treated like a URI whether it is an ID or not. >> >> >> so can you be a bit more specific about how we're not using the URI as a >> URI here? Would you prefer a different way to compare two IDs? Which? > > > It is a structured string and we are ignoring the structure. > It like comparing two timestamps as strings. They might be > the same instant in different timezones, but string comparison > won't catch that. 1) There's a problem with that comparison. For instance, for timestamps comforming to IS08601, there's a well-defined way to parse them and to compare them as dates. There simply isn't a similar comparison method for URLs, unless you restrict yourself to generic URI syntax. 2) Again: *Which* comparison method would you prefer over char-by-char? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 21 04:48:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01999 for ; Sat, 21 Aug 2004 04:48:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L8YG88090095; Sat, 21 Aug 2004 01:34:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L8YGFI090094; Sat, 21 Aug 2004 01:34:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7L8YEjU090065 for ; Sat, 21 Aug 2004 01:34:15 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 16806 invoked by uid 65534); 21 Aug 2004 08:34:09 -0000 Received: from pD953560F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.86.15) by mail.gmx.net (mp022) with SMTP; 21 Aug 2004 10:34:09 +0200 X-Authenticated: #1915285 Message-ID: <41270900.1020400@gmx.de> Date: Sat, 21 Aug 2004 10:34:08 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom WG Subject: Re: ID wording References: <167BB9DC252A3C6BF7154507@diva.verity.com> In-Reply-To: <167BB9DC252A3C6BF7154507@diva.verity.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > ... > This is a change from Tim Bray's declaration of consensus on Aug 5. > That was for "canonical URIs", not "URIs". > > There was one objection, on the grounds that there might be some > RDF out there with non-canonical URIs and that those might end up > in Atom feeds. We can address those by making URI a MUST and > canonical URI a SHOULD, explaining that the SHOULD is only for > legacy IDs. There were *several* objections. Mine was: it doesn't make any sense to require "canonical" unless that buys us something. What does it buy us? > ... >> - IDs MUST be compared character-by-character, no case-mapping, no %xx >> conversion, and so on. > > > This is safe for canonical URIs, though there is no need to > forbid fancier comparisons which also work on canonical URIs. Can you expand on why this is "unsafe" for non-canonical URIs? > If canonical URIs are a SHOULD, then this is a MUST. If they > are a MUST, then this is implementation advice for fast compare, > but not a MUST for protocol correctness. It is. Unless we forbid using multiples URIs that share the same canonical form, it is absolutely required that they are simply compared char-by-char. > In short, we MUST have either canonical URIs or char-by-char > compares. The former is easier to test and probably more robust. > The latter is simple to implement and probably faster (no > canonicalization step). > > Personally, I prefer robustness over premature optimization, > but I haven't seen consensus on that. I prefer spec simplicity. The latter seems to be the simplest thing that the spec can say *and* that will work. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 21 04:57:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02416 for ; Sat, 21 Aug 2004 04:57:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L8i26b092751; Sat, 21 Aug 2004 01:44:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7L8i20Z092750; Sat, 21 Aug 2004 01:44:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7L8i10t092716 for ; Sat, 21 Aug 2004 01:44:02 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so42806rnb for ; Sat, 21 Aug 2004 01:43:59 -0700 (PDT) Received: by 10.38.206.50 with SMTP id d50mr587616rng; Sat, 21 Aug 2004 01:43:59 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sat, 21 Aug 2004 01:43:58 -0700 (PDT) Message-ID: <1f2ed5cd0408210143d802c02@mail.gmail.com> Date: Sat, 21 Aug 2004 10:43:58 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Mark Pilgrim Subject: Re: Atom Feed Autodiscovery Cc: Anne van Kesteren , Atom Syntax In-Reply-To: <14be96d3040819161525cf79a3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41252A1D.8050607@annevankesteren.nl> <14be96d3040819161525cf79a3@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks Mark, this RFC is really good to see - seems very clear and unambiguous, and should make life easier for a lot of people. One minor editorial point - I wonder if it might be possible to flag somehow the parts that are Atom-specific, so it's obvious when questions like Anne's appear whether the place to look for clarification is the Atom or (X)HTML specs. Cheers, Danny. On Thu, 19 Aug 2004 19:15:39 -0400, Mark Pilgrim wrote: > > On Fri, 20 Aug 2004 00:30:53 +0200, Anne van Kesteren > wrote: > > > > Some points I was wondering about: > > > > * Does the TYPE attribute MUST/SHOULD/MAY match the actual MIME type of > > the referenced file? > > (Can 'application/xml' work too?) > > The answer is two-fold. > > 1. As per the HTML specification [1] and the Authoritative Metadata > best practices document [2], the @type attribute is advisory only. > Its purpose is to provide a hint to clients as to what they may > reasonably expect at the other end of @href, without dereferencing it. > If a client chooses to dereference the @href, its Content-Type is > authoritative. > > 2. The only @type value defined for Atom autodiscovery elements is > "application/atom+xml". Any other @type value is not an Atom > autodiscovery element. Publishers who use other values are not > supporting Atom autodiscovery, and client behavior in such instances > is beyond the scope of this specification. > > [1] http://www.w3.org/TR/REC-html40/struct/links.html#adef-type-A > [2] http://www.w3.org/2001/tag/doc/mime-respect.html#specs > > -- > Cheers, > -Mark > > From owner-atom-syntax@mail.imc.org Sat Aug 21 06:19:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05750 for ; Sat, 21 Aug 2004 06:19:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LA5fiL033425; Sat, 21 Aug 2004 03:05:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LA5fsC033424; Sat, 21 Aug 2004 03:05:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7LA5e85033375 for ; Sat, 21 Aug 2004 03:05:41 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 47777 messnum 3886106 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 21 Aug 2004 10:05:35 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail08.svc.cra.dublin.eircom.net (qp 47777) with SMTP; 21 Aug 2004 10:05:35 -0000 Message-ID: <41271E6B.3090600@dehora.net> Date: Sat, 21 Aug 2004 11:05:31 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: "'Atom-Syntax'" Subject: Re: Atom discussed at IPTC Annual General Meeting in Hong Kong, 25-28 June 2004 References: <200408210158.BNZ04687@ms8.netsolmail.com> In-Reply-To: <200408210158.BNZ04687@ms8.netsolmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Atom was discussed at the recent IPTC Standards Groups Annual > General Meeting. Some concern was expressed that Atom might be a competitor > to NewsML... It would probably make sense for us to put some effort into > figuring out how to work better with the IPTC. After all, based on > considerable experience in this field, they define the standards that are > used by the traditional "news syndicators"... The experts in that area should have no problems making informed decisions about the respective technologies. In the meantime they should be aware that 'simpler' technologies have a tendency to undercut other ones, esepcially where high adoption rates are a criteria. I don't we need to do anything to liaise with the IPTC. If they or their members want to contribute to this WG, they can show up here. > "Some concern was expressed over the news that the Atom group were > working with the W3C to adopt Atom as a standard for news content transfer, > and this could be considered to be a direct competitor to NewsML. That opinion would be very much in the eye of the beholder I think. > "The Standards Committe chairman told delegates that the matter had > been considered during the Management Committee Meeting and the view was > that Atom was a Business-to-Consumer model while NewsML was > Business-to-Business. I'd suggest that's not always a useful distinction to make. > However the Management Committee were aware that > adoption by W3C could give a standard considerable momentum and were > considering approaching the W3C to present NewsML 2 as a news exchange > standard." Good for them; there's some interesting stuff in NewsML. The biggest problem with it seems to have been an inability to say no to requirements. And as the saying goes, if you don't like change, you'll like being irrelevant even less. cheers Bill From owner-atom-syntax@mail.imc.org Sat Aug 21 06:35:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06458 for ; Sat, 21 Aug 2004 06:35:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LAPn0n040912; Sat, 21 Aug 2004 03:25:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LAPnUb040911; Sat, 21 Aug 2004 03:25:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LAPmN0040889 for ; Sat, 21 Aug 2004 03:25:49 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 864834F0D6; Sat, 21 Aug 2004 06:25:47 -0400 (EDT) Date: Sat, 21 Aug 2004 06:25:47 -0400 From: Dan Brickley To: Bob Wyman Cc: "'Atom-Syntax'" Subject: Re: Atom discussed at IPTC Annual General Meeting in Hong Kong, 25-28 June 2004 Message-ID: <20040821102547.GB27163@homer.w3.org> References: <200408210158.BNZ04687@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408210158.BNZ04687@ms8.netsolmail.com> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Bob Wyman [2004-08-20 21:59-0400] > > Atom was discussed at the recent IPTC Standards Groups Annual > General Meeting. Some concern was expressed that Atom might be a competitor > to NewsML... It would probably make sense for us to put some effort into > figuring out how to work better with the IPTC. After all, based on > considerable experience in this field, they define the standards that are > used by the traditional "news syndicators"... > Maybe someone could let them know the work is happening at IETF? Dan From owner-atom-syntax@mail.imc.org Sat Aug 21 10:31:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15972 for ; Sat, 21 Aug 2004 10:31:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LEKPcg042540; Sat, 21 Aug 2004 07:20:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LEKP4n042539; Sat, 21 Aug 2004 07:20:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LEKOQA042519 for ; Sat, 21 Aug 2004 07:20:24 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7LEMFgo023131; Sat, 21 Aug 2004 10:22:15 -0400 Message-ID: <41275A22.20008@intertwingly.net> Date: Sat, 21 Aug 2004 10:20:18 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Atom WG Subject: Re: ID wording References: <167BB9DC252A3C6BF7154507@diva.verity.com> <41270900.1020400@gmx.de> In-Reply-To: <41270900.1020400@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > There were *several* objections. Mine was: it doesn't make any sense to > require "canonical" unless that buys us something. What does it buy us? Here's why I voted against the first column in IDSurvey: http://www.imc.org/atom-syntax/mail-archive/msg08194.html http://www.imc.org/atom-syntax/mail-archive/msg08229.html - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Aug 21 11:21:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17803 for ; Sat, 21 Aug 2004 11:21:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LFBkfT050883; Sat, 21 Aug 2004 08:11:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LFBkEM050882; Sat, 21 Aug 2004 08:11:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LFBjmq050868 for ; Sat, 21 Aug 2004 08:11:45 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7LFBjh8004237 for ; Sat, 21 Aug 2004 11:11:46 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOA43361 (AUTH bob@wyman.us); Sat, 21 Aug 2004 11:11:44 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Atom WG'" Subject: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Date: Sat, 21 Aug 2004 11:14:00 -0400 Message-ID: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C4876F.F5F043A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C4876F.F5F043A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit At http://del.icio.us/rss/ you'll find an RSS/RDF feed which contains entries who purpose is to link to and categorize pages that users have found interesting. In each RSS item, the field points to some site other than del.icio.us. There is generally no correlation between the text provided and the content which is linked to. The entry in the feed is not an "alternative" to the page linked to -- its function is simply to provide a pointer, potentially with some commentary in the description and some classification data. (A sample entry will be found below.) I have no relationship with the del.icio.us site, however, I'm curious if anyone can suggest how they might convert from RSS to Atom in the future? The Atom format spec says: "atom:entry elements MUST contain at least one atom:link element with a rel attribute value of 'alternate'." However, there is no apparent candidate for a page that is the "alternate" of a del.icio.us item since these items are only listed on category pages and don't have item specific pages on the site. Given that individual items can be listed on multiple pages (if the item has multiple topics or keywords), even if one decided that the "alternate" was to be the category page, they would run afoul of the requirement in Atom that an entry can only have *one* link of type "alternate." Can the del.icio.us function be provided via Atom without violating the Atom format specification or requiring major changes to the way the site works today? bob wyman - Heraclitus sayz (the Return of the Lo-Fi) http://heraclitussayz.blogspot.com/ Heraclitus sayz (the Return of the Lo-Fi) omit35 blog_mp3 music - - ------=_NextPart_000_000D_01C4876F.F5F043A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
   =20 At http://del.icio.us/rss/ you'll=20 find an RSS/RDF feed which contains entries who purpose is to link to = and=20 categorize pages that users have found interesting. In each RSS item, = the=20 <link> field points to some site other than del.icio.us. There is=20 generally no correlation between the <description> text provided = and the=20 content which is linked to. The entry in the feed is not an = "alternative" to the=20 page linked to -- its function is simply to provide a pointer, = potentially with=20 some commentary in the description and some classification data. (A = sample entry=20 will be found below.)
    I=20 have no relationship with the del.icio.us site, however, I'm curious if = anyone=20 can suggest how they might convert from RSS to Atom in the future?=20
   =20 The Atom format spec says: "atom:entry elements MUST contain at = least one=20 atom:link element with a rel attribute value of 'alternate'." However, = there is=20 no apparent candidate for a page that is the "alternate" of a = del.icio.us item=20 since these items are only listed on category pages and don't have item = specific=20 pages on the site. Given that individual items can be listed on multiple = pages=20 (if the item has multiple topics or keywords), even if one decided that = the=20 "alternate" was to be the category page, they would run afoul of the = requirement=20 in Atom that an entry can only have *one* link of type=20 "alternate." 
    Can the del.icio.us function be provided via = Atom=20 without violating the Atom format specification or requiring major = changes to=20 the way the site works today?
        bob=20 wyman
- <item rdf:about=3D"http://heraclitussayz.blogspot.com/<= /B>">
  <title>Heraclitus = sayz (the=20 Return of the Lo-Fi)</title>
  <link>http://heraclitussayz.blogspot.com/</link>
  <description>Heraclitus = sayz (the=20 Return of the Lo-Fi)</description>
  <dc:creator>omit35</dc:creator>
  <dc:subject>blog_mp3=20 music</dc:subject>
- <taxo:topics>
- <rdf:Bag>
  <rdf:li resource=3D"http://del.icio.us/omit35/blog_mp3" = />=20
  <rdf:li resource=3D"http://del.icio.us/omit35/music<= FONT=20 color=3D#0000ff>" = />=20
  </rdf:Bag>
  </taxo:topics>
</item>
 
------=_NextPart_000_000D_01C4876F.F5F043A0-- From owner-atom-syntax@mail.imc.org Sat Aug 21 11:43:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18565 for ; Sat, 21 Aug 2004 11:43:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LFYZ18054032; Sat, 21 Aug 2004 08:34:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LFYZOq054031; Sat, 21 Aug 2004 08:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LFYY4l054022 for ; Sat, 21 Aug 2004 08:34:34 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from cpanel by web02.designerslab.net with local (Exim 4.34) id 1ByXt2-00029Q-5C; Sat, 21 Aug 2004 15:34:32 +0000 Received: from 24.215.149.188 ([24.215.149.188]) by www.franklinmint.fm (IMP) with HTTP for ; Sat, 21 Aug 2004 15:34:32 +0000 Message-ID: <1093102472.41276b880eac8@www.franklinmint.fm> Date: Sat, 21 Aug 2004 15:34:32 +0000 From: Robert Sayre To: bob@wyman.us Cc: "'Atom WG'" Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> In-Reply-To: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 24.215.149.188 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [32001 528] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: /usr/local/cpanel/base/horde/imp Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Bob Wyman : > At http://del.icio.us/rss/ you'll find an > RSS/RDF feed which contains entries who purpose is to link to and > categorize pages that users have found interesting. In each RSS item, > the field points to some site other than del.icio.us. There is > generally no correlation between the text provided and the > content which is linked to. The entry in the feed is not an > "alternative" to the page linked to -- its function is simply to provide > a pointer, potentially with some commentary in the description and some > classification data. Here's an example in Atom: http://www.dashes.com/links/atom.xml Anil is forced to relegate the actual alternate representation of his entries to "related" in order to get the the linked page to show up in the content pane of an aggregator (RSS Bandit does this, I haven't tried this feed elsewhere). This is why people want content indirection. It's already being done, in a broken way. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 21 13:30:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23006 for ; Sat, 21 Aug 2004 13:30:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LHLZxY070835; Sat, 21 Aug 2004 10:21:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LHLZke070834; Sat, 21 Aug 2004 10:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LHLX8L070818 for ; Sat, 21 Aug 2004 10:21:34 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7LHNUne030585; Sat, 21 Aug 2004 13:23:31 -0400 Message-ID: <4127849D.7020300@intertwingly.net> Date: Sat, 21 Aug 2004 13:21:33 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Atom WG'" Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> In-Reply-To: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Can the del.icio.us function be provided via Atom without violating > the Atom format specification or requiring major changes to the way the > site works today? In general, multiple del.icio.us entries are related to a given web page. Using a simple query, you can see a single page which contains all of them, for example: http://del.icio.us/url/?url=http://www.intertwingly.net/blog/2004/07/05/Tasty This page redirects to http://del.icio.us/url/47febb675b419260bee19862d6479e0d Now, if each of these entries were identified with an id, they could be uniquely referenced by a fragment identifier, e.g.: http://del.icio.us/url/47febb675b419260bee19862d6479e0d#17 - - - Whether this constitutes a "major change", or if the requirement that an "atom:entry elements MUST contain at least one atom:link element with a rel attribute value of 'alternate'", or if we simply decide that this is not a valid scenario for Atom can be debated. - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Aug 21 13:32:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23098 for ; Sat, 21 Aug 2004 13:32:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LHN6xI071413; Sat, 21 Aug 2004 10:23:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LHN6XU071409; Sat, 21 Aug 2004 10:23:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LHN3KV071338 for ; Sat, 21 Aug 2004 10:23:04 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7LHOtOZ030643; Sat, 21 Aug 2004 13:24:55 -0400 Message-ID: <412784F2.9070602@intertwingly.net> Date: Sat, 21 Aug 2004 13:22:58 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: "'Atom WG'" , Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> <1093102472.41276b880eac8@www.franklinmint.fm> In-Reply-To: <1093102472.41276b880eac8@www.franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Here's an example in Atom: > http://www.dashes.com/links/atom.xml > > Anil is forced to relegate the actual alternate representation of his entries to > "related" in order to get the the linked page to show up in the content pane of > an aggregator (RSS Bandit does this, I haven't tried this feed elsewhere). Sigh. This is just so busted. Dare, what can be done to fix RSSBandit? Is there an additional clarification in the specification needed? - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Aug 21 13:45:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23616 for ; Sat, 21 Aug 2004 13:45:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LHVsiV072677; Sat, 21 Aug 2004 10:31:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LHVsMj072676; Sat, 21 Aug 2004 10:31:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LHVsGD072660 for ; Sat, 21 Aug 2004 10:31:54 -0700 (PDT) (envelope-from grayrest@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so37159rnk for ; Sat, 21 Aug 2004 10:31:54 -0700 (PDT) Received: by 10.38.70.46 with SMTP id s46mr499813rna; Sat, 21 Aug 2004 10:31:54 -0700 (PDT) Received: by 10.38.70.69 with HTTP; Sat, 21 Aug 2004 10:31:54 -0700 (PDT) Message-ID: <476b71e804082110311d2bb57c@mail.gmail.com> Date: Sat, 21 Aug 2004 13:31:54 -0400 From: grayrest Reply-To: grayrest To: Tim Bray Subject: Re: PaceIdConstruct Cc: Atom WG In-Reply-To: <979E9CC8-F2C4-11D8-806F-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> <979E9CC8-F2C4-11D8-806F-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 20 Aug 2004 09:18:37 -0700, Tim Bray wrote: > I think it's better to err on the side of too many rather > than too few examples (too many RFCs and W3C RECs go the other way). > So please retain as many as possible. +1 At minimum, examples provide unit test cases that you don't have to invent yourself. Karl From owner-atom-syntax@mail.imc.org Sat Aug 21 13:53:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23944 for ; Sat, 21 Aug 2004 13:53:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LHj1n8075450; Sat, 21 Aug 2004 10:45:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LHj1Gq075447; Sat, 21 Aug 2004 10:45:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LHj0be075432 for ; Sat, 21 Aug 2004 10:45:00 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7LHklT4031648 for ; Sat, 21 Aug 2004 13:46:47 -0400 Message-ID: <41278A12.3010309@intertwingly.net> Date: Sat, 21 Aug 2004 13:44:50 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom WG'" Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> <4127849D.7020300@intertwingly.net> In-Reply-To: <4127849D.7020300@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Whether this constitutes a "major change", or if the requirement that an Insert "we should drop" between "if" and "the". ^^^^^^ > "atom:entry elements MUST contain at least one atom:link element with a > rel attribute value of 'alternate'", or if we simply decide that this is > not a valid scenario for Atom can be debated. - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Aug 21 14:08:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24473 for ; Sat, 21 Aug 2004 14:08:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LI13rZ078011; Sat, 21 Aug 2004 11:01:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LI134n078010; Sat, 21 Aug 2004 11:01:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7LI12F6077978 for ; Sat, 21 Aug 2004 11:01:02 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040821180059.75331.qmail@web41212.mail.yahoo.com> Received: from [67.160.44.197] by web41212.mail.yahoo.com via HTTP; Sat, 21 Aug 2004 11:00:59 PDT Date: Sat, 21 Aug 2004 11:00:59 -0700 (PDT) From: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: Sam Ruby , Robert Sayre Cc: "'Atom WG'" , Dare Obasanjo In-Reply-To: <412784F2.9070602@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Sam Ruby wrote: > > > > Here's an example in Atom: > > http://www.dashes.com/links/atom.xml > > > > Anil is forced to relegate the actual alternate > representation of his entries to > > "related" in order to get the the linked page to > show up in the content pane of > > an aggregator (RSS Bandit does this, I haven't > tried this feed elsewhere). > > Sigh. This is just so busted. Dare, what can be > done to fix RSSBandit? > Is there an additional clarification in the > specification needed? RSS Bandit only recognizes while ignoring both and element, no? [[ I have no relationship with the del.icio.us site, however, I'm curious if anyone can suggest how they might convert from RSS to Atom in the future? The Atom format spec says: "atom:entry elements MUST contain at least one atom:link element with a rel attribute value of 'alternate'." However, there is no apparent candidate for a page that is the "alternate" of a del.icio.us item since these items are only listed on category pages and don't have item specific pages on the site. ]] Good question. What should be the alternate if a blog post doesn't have a (permalinked) individual reflection somewhere on the web? [[ Given that individual items can be listed on multiple pages (if the item has multiple topics or keywords), even if one decided that the "alternate" was to be the category page, they would run afoul of the requirement in Atom that an entry can only have *one* link of type "alternate." Can the del.icio.us function be provided via Atom without violating the Atom format specification or requiring major changes to the way the site works today? ]] I hate to bring this up, but this is exactly the kind of case the extensible version of would have been good for. I don't think Atom in its present form is capable of expressing the information in the RSS 1.0 feed in a non-lossy machine-readable way. Cheers, Danny. - Heraclitus sayz (the Return of the Lo-Fi) http://heraclitussayz.blogspot.com/ Heraclitus sayz (the Return of the Lo-Fi) omit35 blog_mp3 music - - From owner-atom-syntax@mail.imc.org Sat Aug 21 14:18:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24970 for ; Sat, 21 Aug 2004 14:18:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LIAW1C079485; Sat, 21 Aug 2004 11:10:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LIAWhc079484; Sat, 21 Aug 2004 11:10:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LIAVVS079478 for ; Sat, 21 Aug 2004 11:10:32 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7LIAYT6018652; Sat, 21 Aug 2004 14:10:34 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOA78984 (AUTH bob@wyman.us); Sat, 21 Aug 2004 14:10:33 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , Cc: "'Atom WG'" Subject: RE: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Date: Sat, 21 Aug 2004 14:12:49 -0400 Message-ID: <001101c487aa$788d9030$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <1093102472.41276b880eac8@www.franklinmint.fm> Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > http://www.dashes.com/links/atom.xml > Anil is forced to relegate the actual alternate representation of his > entries to "related" in order to get the the linked page to show up in > the content pane of an aggregator I think there is more going on here than a relegating of the links from "alternate" to "related." What Anil is doing in his Atom feed is making a false statement... I believe it is fair to say that the common understanding of "alternate" is that it points to a page which is, in fact, an "alternate" presentation of the same data which is in the entry itself. Thus, the "alternate" should contain some alternative representation of the element of the entry. This is not the case in Anil's feed since the in Anil's feed is a comment *about* the page which is said to be the alternate rather than being an actual alternate of that page. It seems wrong that it should be necessary to make a false statement in order to get the desired behavior. bob wyman From owner-atom-syntax@mail.imc.org Sat Aug 21 14:39:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26016 for ; Sat, 21 Aug 2004 14:39:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LIU7gn082893; Sat, 21 Aug 2004 11:30:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LIU7nj082892; Sat, 21 Aug 2004 11:30:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7LIU6A1082867 for ; Sat, 21 Aug 2004 11:30:07 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 92779 messnum 3870713 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 21 Aug 2004 18:30:05 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail08.svc.cra.dublin.eircom.net (qp 92779) with SMTP; 21 Aug 2004 18:30:05 -0000 Message-ID: <412794A8.8060800@dehora.net> Date: Sat, 21 Aug 2004 19:30:00 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: "'Atom WG'" Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <001101c487aa$788d9030$6400a8c0@wyman.us> In-Reply-To: <001101c487aa$788d9030$6400a8c0@wyman.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > I believe it is fair to say that the common understanding of > "alternate" That's the problem, right there. cheers Bill From owner-atom-syntax@mail.imc.org Sat Aug 21 14:51:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26478 for ; Sat, 21 Aug 2004 14:51:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LIhw30086609; Sat, 21 Aug 2004 11:43:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LIhwsQ086608; Sat, 21 Aug 2004 11:43:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LIhvX8086599 for ; Sat, 21 Aug 2004 11:43:57 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1ByaqL-0007L5-TK; Sat, 21 Aug 2004 18:43:58 +0000 Message-ID: <412797EE.3080904@franklinmint.fm> Date: Sat, 21 Aug 2004 14:43:58 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Atom WG'" , =?ISO-8859-1?Q?Bill=5Fde=5Fh=D3ra?= Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <001101c487aa$788d9030$6400a8c0@wyman.us> In-Reply-To: <001101c487aa$788d9030$6400a8c0@wyman.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Thus, the "alternate" should contain some alternative representation of > the element of the entry. This is not the case in Anil's feed > since the in Anil's feed is a comment *about* the page which > is said to be the alternate rather than being an actual alternate of > that page. It seems wrong that it should be necessary to make a false > statement in order to get the desired behavior. Right. I agree completely. Anil is using the "alternate" link with the semantics of the RSS2 link element[0]. In NNW and Shrook (shrook shows the related link), clicking the title will bring you to the link specified in "alternate". This behavior *is* annoying for this type of blog. Mark Pilgrim's linkblog [1] doesn't make this false statement, and clicking on the title then brings you to a rather boring diveintomark.org page with a link that you click to get to the article... ack. I see Bill has responded, implying that the common understanding of "alternate" is wrong, but I'm not following him. I like to think of as "what you see when you pay more attention." In this case, the author just wants you to visit the page in question, which is a little different than "alternate" in any sense, isn't it? Robert Sayre [0] http://blogs.law.harvard.edu/tech/rss#hrelementsOfLtitemgt [1] http://diveintomark.org/xml/blink.xml From owner-atom-syntax@mail.imc.org Sat Aug 21 15:54:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00656 for ; Sat, 21 Aug 2004 15:54:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LJjEBc098180; Sat, 21 Aug 2004 12:45:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LJjE63098177; Sat, 21 Aug 2004 12:45:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LJjDNb098164 for ; Sat, 21 Aug 2004 12:45:13 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7LJlBH8004360; Sat, 21 Aug 2004 15:47:11 -0400 Message-ID: <4127A649.7070603@intertwingly.net> Date: Sat, 21 Aug 2004 15:45:13 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Atom WG Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> <1f2ed5cd0408211111548de5e@mail.gmail.com> In-Reply-To: <1f2ed5cd0408211111548de5e@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > > I hate to bring this up, but this is exactly the kind of case the > extensible version of would have been good for. I don't think > Atom in its present form is capable of expressing the information in > the RSS 1.0 feed in a non-lossy machine-readable way. For reference, here is the complete RSS 1.0 definition of the link element[1]: The item's URL. - Sam Ruby [1] http://web.resource.org/rss/1.0/spec#s5.5.2 From owner-atom-syntax@mail.imc.org Sat Aug 21 15:54:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00709 for ; Sat, 21 Aug 2004 15:54:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LJkSO1098389; Sat, 21 Aug 2004 12:46:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LJkSZ8098388; Sat, 21 Aug 2004 12:46:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LJkRBT098381 for ; Sat, 21 Aug 2004 12:46:27 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7LJmPHu004413; Sat, 21 Aug 2004 15:48:25 -0400 Message-ID: <4127A694.9060107@intertwingly.net> Date: Sat, 21 Aug 2004 15:46:28 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: "'Atom WG'" Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <001101c487aa$788d9030$6400a8c0@wyman.us> <412794A8.8060800@dehora.net> In-Reply-To: <412794A8.8060800@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > Bob Wyman wrote: > >> I believe it is fair to say that the common understanding of >> "alternate" > > That's the problem, right there. Can you be more specific as to what the problem as you see it is? And I will ask the same question I asked to Dare: Is there an additional clarification in the specification needed? - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Aug 21 16:27:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02319 for ; Sat, 21 Aug 2004 16:27:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LKK1Ch004106; Sat, 21 Aug 2004 13:20:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LKK1T8004105; Sat, 21 Aug 2004 13:20:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LKK0as004083 for ; Sat, 21 Aug 2004 13:20:00 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so12111rnk for ; Sat, 21 Aug 2004 13:19:59 -0700 (PDT) Received: by 10.38.92.62 with SMTP id p62mr371662rnb; Sat, 21 Aug 2004 13:19:59 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Sat, 21 Aug 2004 13:19:59 -0700 (PDT) Message-ID: <14be96d304082113196699539b@mail.gmail.com> Date: Sat, 21 Aug 2004 16:19:59 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: Sam Ruby , Atom WG In-Reply-To: <20040821180059.75331.qmail@web41212.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040821180059.75331.qmail@web41212.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 21 Aug 2004 11:00:59 -0700 (PDT), Dare Obasanjo wrote: > RSS Bandit only recognizes > while ignoring both and rel="via /> because they are not in the Atom 0.3 > spec[0,1]. Thank you for once again writing code that is meticulously spec-compliant, but useless. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Sat Aug 21 16:29:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02447 for ; Sat, 21 Aug 2004 16:29:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LKMNub004387; Sat, 21 Aug 2004 13:22:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LKMNQ1004386; Sat, 21 Aug 2004 13:22:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7LKMMol004372 for ; Sat, 21 Aug 2004 13:22:22 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040821202222.50138.qmail@web41214.mail.yahoo.com> Received: from [67.161.110.205] by web41214.mail.yahoo.com via HTTP; Sat, 21 Aug 2004 13:22:22 PDT Date: Sat, 21 Aug 2004 13:22:22 -0700 (PDT) From: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: Mark Pilgrim Cc: Sam Ruby , Atom WG In-Reply-To: <14be96d304082113196699539b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Mark Pilgrim wrote: > > Thank you for once again writing code that is > meticulously > spec-compliant, but useless. You're welcome. I aim to please. :) ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Sat Aug 21 17:39:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06223 for ; Sat, 21 Aug 2004 17:39:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LLUfEC014768; Sat, 21 Aug 2004 14:30:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7LLUf1l014767; Sat, 21 Aug 2004 14:30:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LLUe0f014758 for ; Sat, 21 Aug 2004 14:30:40 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7LLUfhA003229; Sat, 21 Aug 2004 17:30:42 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOB20139 (AUTH bob@wyman.us); Sat, 21 Aug 2004 17:30:41 -0400 (EDT) Message-Id: <200408212130.BOB20139@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Mark Pilgrim'" , "'Dare Obasanjo'" Cc: "'Sam Ruby'" , "'Atom WG'" Subject: RE: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Date: Sat, 21 Aug 2004 17:30:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <14be96d304082113196699539b@mail.gmail.com> Thread-Index: AcSHvcI03SvN4RzJT8CCuy8tLstK/QABSCUA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: >On Sat, 21 Aug 2004 11:00:59 -0700 (PDT), Dare Obasanjo > wrote: >> RSS Bandit only recognizes >> while ignoring both and > rel="via /> because they are not in the Atom 0.3 >> spec[0,1]. > Thank you for once again writing code that is meticulously > spec-compliant, but useless. PubSub.com also ignores "related" and "via". However, I strongly believe that both Dare's RSS Bandit and the PubSub service are "useful"... Certainly our users seem to agree with us... For there to be interoperability we need to agree on common ground. The Atom spec should define that common ground better than RSS, with its vast variety of flavors, has done. We look to Atom to provide a more rigorous specification that will make interop easier. While we're waiting for Atom to be finalized, I think we should all avoid making or recognizing informal extensions to Atom as documented. By doing so, we will get a much better idea of what is missing from the core set of Atom features and we can avoid some potential for future interop issues when things that might be implemented as private extensions today become differently defined standardized elements tomorrow. Our goal should be to write a specification that allows (in Mark's words [1]) "assholes", "morons" and "angels" to all interoperate correctly and comfortably. The example that I presented at the beginning of this thread concerning del.icio.us, is instructive. Anil Dash has "solved" the del.icio.us problem by 1) Violating the common understanding of the meaning of "alternate" and by 2) Introducing the non-standard "rel='related'" to do what most would have expected "alternate" to do. Certainly, there are all sorts of creative solutions to problems that can be achieved using Dash's methods or other hacks. However, such hacks tend to harm interop in the long run even if they appear, by hiding an issue, to solve problems in the near term. bob wyman [1] http://diveintomark.org/archives/2004/08/16/specs From owner-atom-syntax@mail.imc.org Sun Aug 22 04:43:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13909 for ; Sun, 22 Aug 2004 04:43:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7M8PUEk075080; Sun, 22 Aug 2004 01:25:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7M8PUNP075079; Sun, 22 Aug 2004 01:25:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7M8PUE3075059; Sun, 22 Aug 2004 01:25:30 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 115BA4F23B; Sun, 22 Aug 2004 04:25:27 -0400 (EDT) Message-Id: <4.2.0.58.J.20040822162343.054512b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 22 Aug 2004 17:25:23 +0900 To: Paul Hoffman / IMC , Atom WG From: Martin Duerst Subject: Re: PaceIdConstruct In-Reply-To: References: <4124EEE2.6000703@annevankesteren.nl> <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124EEE2.6000703@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 13:26 04/08/19 -0700, Paul Hoffman / IMC wrote: >At 8:18 PM +0200 8/19/04, Anne van Kesteren wrote: >>That is not a valid URI. However, it is a valid IRI which will become a >>recommendation soon[1]. >Saying "will become" in a context like this is premature. There are many >hurdles between "IETF last call" and "accepted as a standard". I agree with Paul that the future is difficult to predict. However, I think that 'accepted as a standard' isn't clear at all. Who accepts? What kind of 'standard'? I think it's probably better to say 'approved by the IESG as an IETF Proposed Standard'. That's the next formal step after IETF Last Call, and is clearly defined. Of course, both IRIs and Atom eventually hope to become IETF (Full) Standard. But that will take quite some time in both cases. In addition, please note that you don't need to take a 'wait and see' only attitude. If you think that it would be good for Atom to use IRIs, it might be a good idea to make an IETF Last Call comment on the IRI spec to say something like "I'd like IRIs to be used in Atom, so please move this spec ahead". Regards, Martin. From owner-atom-syntax@mail.imc.org Sun Aug 22 07:18:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19089 for ; Sun, 22 Aug 2004 07:18:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MB7mOJ044555; Sun, 22 Aug 2004 04:07:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7MB7mjR044554; Sun, 22 Aug 2004 04:07:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MB7mpQ044547 for ; Sun, 22 Aug 2004 04:07:48 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 86ADE4EFF6; Sun, 22 Aug 2004 07:07:47 -0400 (EDT) Message-Id: <4.2.0.58.J.20040822173548.05025ed0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 22 Aug 2004 17:37:05 +0900 To: Asbj=?ISO-2022-JP?B?GyRCj1MbKEI=?=n Ulsberg , "Anne van Kesteren" From: Martin Duerst Subject: Re: PaceIdConstruct Cc: Atom-Syntax In-Reply-To: References: <4124EEE2.6000703@annevankesteren.nl> <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124EEE2.6000703@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 20:55 04/08/19 +0200, Asbj$BS(Bn Ulsberg wrote: >The fact that atom:id is not going to be dereferencable makes it even >easier to deploy IRI's, since they're only going to be stored as UTF-8 >somewhere, and not be used in some transport protocol layer to dereference >resources. Just a small point: There is no requirement to store IRIs as UTF-8. IRIs are sequences of characters. In many cases they may be stored in UTF-16, or something else. Regards, Martin. From owner-atom-syntax@mail.imc.org Sun Aug 22 12:47:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06344 for ; Sun, 22 Aug 2004 12:47:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MGcAwo093625; Sun, 22 Aug 2004 09:38:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7MGcAac093624; Sun, 22 Aug 2004 09:38:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MGc3rj093608 for ; Sun, 22 Aug 2004 09:38:04 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 23 Aug 2004 02:44:32 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 Aug 2004 02:37:29 +1000 Subject: Re: ID wording From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41270900.1020400@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: Content-Transfer-Encoding: 7bit On 21/8/04 6:34 PM, "Julian Reschke" wrote: >> In short, we MUST have either canonical URIs or char-by-char >> compares. The former is easier to test and probably more robust. >> The latter is simple to implement and probably faster (no >> canonicalization step). >> >> Personally, I prefer robustness over premature optimization, >> but I haven't seen consensus on that. > > I prefer spec simplicity. The latter seems to be the simplest thing that > the spec can say *and* that will work. +1 If we don't even mention canonicalisation, not even as a suggestive SHOULD, then we don't have to explain it in the spec. One less hurdle for the busy developer. Plus it weakens the argument that id comparisons must be done by string comparison. e. From owner-atom-syntax@mail.imc.org Sun Aug 22 18:27:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23949 for ; Sun, 22 Aug 2004 18:27:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MMI94P040272; Sun, 22 Aug 2004 15:18:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7MMI9Nv040271; Sun, 22 Aug 2004 15:18:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MMI8Tp040247 for ; Sun, 22 Aug 2004 15:18:08 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id PAA23455 for ; Sun, 22 Aug 2004 15:18:06 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id PAA21261 for ; Sun, 22 Aug 2004 15:18:06 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Sun, 22 Aug 2004 15:18:05 -0700 Received: from adsl-64-166-133-246.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7MMI2lB011277 for ; Sun, 22 Aug 2004 15:18:02 -0700 (PDT) Date: Sun, 22 Aug 2004 15:18:07 -0700 From: Walter Underwood To: Atom WG Subject: Re: ID wording Message-ID: <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <412707CE.3010609@gmx.de> References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Saturday, August 21, 2004 10:29 AM +0200 Julian Reschke wrote: > > 1) There's a problem with that comparison. For instance, for timestamps > comforming to IS08601, there's a well-defined way to parse them and to > compare them as dates. There simply isn't a similar comparison method > for URLs, unless you restrict yourself to generic URI syntax. 2396bis, section 6. > 2) Again: *Which* comparison method would you prefer over char-by-char? I did not say I preferred another method. I said that the spec does not need to restrict implementations to char-by-char if canonical URIs are required. Many libraries will provide an equals method for their URI objects, and that is probably not char-by-char. Atom will require programmers to avoid the obvious URI comparison routines and do something different. Again, we require apples (URIs) and require that they be treated as oranges (strings). If we require URIs, we should require good URI practices. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sun Aug 22 18:41:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24753 for ; Sun, 22 Aug 2004 18:41:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MMYkth042446; Sun, 22 Aug 2004 15:34:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7MMYkHs042440; Sun, 22 Aug 2004 15:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7MMYjDU042424 for ; Sun, 22 Aug 2004 15:34:45 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 59776 messnum 439155 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 22 Aug 2004 22:34:44 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail05.svc.cra.dublin.eircom.net (qp 59776) with SMTP; 22 Aug 2004 22:34:44 -0000 Message-ID: <41291F80.6060809@dehora.net> Date: Sun, 22 Aug 2004 23:34:40 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > Many libraries will provide an equals method for their URI objects, > and that is probably not char-by-char. Atom will require programmers > to avoid the obvious URI comparison routines and do something different. I don't see the problem. > Again, we require apples (URIs) and require that they be treated > as oranges (strings). Again, I don't see the problem: Apples: key generation. Oranges: key comparison. cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 22 18:44:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24870 for ; Sun, 22 Aug 2004 18:44:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MMaLkI042627; Sun, 22 Aug 2004 15:36:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7MMaLY8042626; Sun, 22 Aug 2004 15:36:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MMaKvj042607 for ; Sun, 22 Aug 2004 15:36:20 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id PAA23861 for ; Sun, 22 Aug 2004 15:36:20 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id PAA21989 for ; Sun, 22 Aug 2004 15:36:20 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Sun, 22 Aug 2004 15:36:20 -0700 Received: from adsl-64-166-133-246.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7MMaIlB011332 for ; Sun, 22 Aug 2004 15:36:19 -0700 (PDT) Date: Sun, 22 Aug 2004 15:36:23 -0700 From: Walter Underwood To: Atom WG Subject: Re: ID wording Message-ID: <156BF90D0468B3C6D39B495D@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Sunday, August 22, 2004 3:18 PM -0700 Walter Underwood wrote: > > Again, we require apples (URIs) and require that they be treated > as oranges (strings). > > If we require URIs, we should require good URI practices. More accurately, we should not forbid good URI practices. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sun Aug 22 19:11:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25837 for ; Sun, 22 Aug 2004 19:11:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MN11sJ046046; Sun, 22 Aug 2004 16:01:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7MN11PU046045; Sun, 22 Aug 2004 16:01:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7MN10FI046037 for ; Sun, 22 Aug 2004 16:01:00 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.164.220]) by mail.mnot.net (Postfix) with ESMTP id E3B99727D; Sun, 22 Aug 2004 16:01:03 -0700 (PDT) In-Reply-To: <4.2.0.58.J.20040822162343.054512b0@localhost> References: <4124EEE2.6000703@annevankesteren.nl> <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124EEE2.6000703@annevankesteren.nl> <4.2.0.58.J.20040822162343.054512b0@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23922DCA-F48F-11D8-82BE-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceIdConstruct Date: Sun, 22 Aug 2004 16:01:02 -0700 To: Martin Duerst X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Martin, Just curious -- what's the status of IRI support in implementations? Cheers, On Aug 22, 2004, at 1:25 AM, Martin Duerst wrote: > > At 13:26 04/08/19 -0700, Paul Hoffman / IMC wrote: > >> At 8:18 PM +0200 8/19/04, Anne van Kesteren wrote: >>> That is not a valid URI. However, it is a valid IRI which will >>> become a recommendation soon[1]. >> Saying "will become" in a context like this is premature. There are >> many hurdles between "IETF last call" and "accepted as a standard". > > I agree with Paul that the future is difficult to predict. However, > I think that 'accepted as a standard' isn't clear at all. > Who accepts? What kind of 'standard'? I think it's probably > better to say 'approved by the IESG as an IETF Proposed Standard'. > That's the next formal step after IETF Last Call, and is clearly > defined. Of course, both IRIs and Atom eventually hope to become > IETF (Full) Standard. But that will take quite some time in both > cases. > > In addition, please note that you don't need to take a 'wait and see' > only attitude. If you think that it would be good for Atom to use IRIs, > it might be a good idea to make an IETF Last Call comment on the IRI > spec > to say something like "I'd like IRIs to be used in Atom, so please > move this spec ahead". > > Regards, Martin. > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 23 07:06:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28799 for ; Mon, 23 Aug 2004 07:06:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NAsbGE013177; Mon, 23 Aug 2004 03:54:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NAsbGF013176; Mon, 23 Aug 2004 03:54:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pulse.betaversion.org ([62.140.213.123]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7NAsYWF013136 for ; Mon, 23 Aug 2004 03:54:36 -0700 (PDT) (envelope-from pier@betaversion.org) Received: (qmail 28388 invoked from network); 23 Aug 2004 10:54:32 -0000 Received: from unknown (HELO ?10.11.155.45?) (pier@62.140.213.2) by pulse.betaversion.org with SMTP; 23 Aug 2004 10:54:32 -0000 In-Reply-To: References: <9C38CA5A-F23B-11D8-B4D3-000A95984AEA@betaversion.org> <412560AD.3030700@franklinmint.fm> <9CF4CE78-F281-11D8-B4D3-000A95984AEA@betaversion.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--1012841612; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Pier Fumagalli Subject: Re: Syndication of updates and deletions of content Date: Mon, 23 Aug 2004 11:54:35 +0100 To: Walter Underwood X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--1012841612 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 20 Aug 2004, at 17:17, Walter Underwood wrote: > --On Friday, August 20, 2004 9:19 AM +0100 Pier Fumagalli > wrote: >> >> Absolutely... I work for a publication company... NOTHING gets ever >> "deleted" (ever - ever - ever). > > This depends on the organization. > > When I was working with the search for ABCNews.com, they had permission > to keep wire stories on their site for two weeks. After two weeks, > they were deleted from the site. All the wire stories were deleted > (always - always - always). Deleted, or simply "locked away and they cannot go on the site anymore" ??? Because we do the latter (embargo dates, like any other publication), but that's far from getting rid of the content itself... Pier --Apple-Mail-2--1012841612 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwttIjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTA3MDE0MjIwWhcNMDUwMTA2MDE0MjIwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRwaWVyQGJldGF2ZXJzaW9u Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMC/E+M4UqeEBnSTj0AIMX9oMWSo 9Te7VUPPvINPSKKLEElGaottQeJaYRSlfGIjUyXkzTlbw0MFAPaqfU97t+5xeNkighKu7ZcVIPfz AARv5+wp+gON5uSNV2GzP0rPwAbUDIG2zaSonJlN7whVG5fO9G1u0oYaWolpgKUAc3T5P5Gv737L G1iSxrnl9DQlVDIuZWrcgWYX/MFFlf7prXXm6lS08lYhGi0NrIf5SploZzMG+uHHzVDgV8WCTQr1 hXB825VLhnWw4GPFx5qLVgElctVz88S/+t8O/+1kRf3ky8SsewfyCTuDAk4XHzfb7M5bECiZ1yni dhW+sD1y/TsCAwEAAaMxMC8wHwYDVR0RBBgwFoEUcGllckBiZXRhdmVyc2lvbi5vcmcwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAjeSEnk3U1P46rHiBGJP7StkQg/DVkw4ModEYCEwxm 8QYxQPGMciXn2goZ5ahK6Uu8Rfa+ZPSxV96VFsOlc3oFF02VYsrRy+xJukuSMY0z/0UvHnTZmVfm CJpxMoVMYQO3fC2XdmCNASu8FbvOgaS71fQf3b0wgebLeLROR7u5XjCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC20iMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgyMzEwNTQzNVowIwYJKoZIhvcNAQkEMRYEFNH+ mZ/qQP4tjJHTg8cRSPbkelVUMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLbSIwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC20iMA0GCSqGSIb3DQEBAQUABIIBAChu 0CH6vDcSiQeDtgNrNhbQy29Wecnr20xQLccw97p1qG2xDFn4aqq38df6PCEaGrhOZMEIsqodYMZo sa99y8ibLTXPhOsldiY5KVCDHJx28e7q2v5UJGJfQE2pCt16diwT217TPyw9kQg/sqyLgjvrMxgz 4A0AyDbVdBcrFuoK8fb4e2qIp4Xmb4bR/4Ql9ZfLvTh5dcAhOwZq3Y378JLaIUmiVpRUMj6QNsPL rmM8qYEdwoMPWzy2qITu0sFFoDkM0QHRI8ff4jbIKHf9sXIiMTUtSRB6PB8rK0hHxZxyyP2D/KoZ CSIHED5sUs/Ny5DbrbZ92h6qTHFOn/qyUfcAAAAAAAA= --Apple-Mail-2--1012841612-- From owner-atom-syntax@mail.imc.org Mon Aug 23 07:07:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28874 for ; Mon, 23 Aug 2004 07:07:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NAtNv4013381; Mon, 23 Aug 2004 03:55:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NAtNKF013379; Mon, 23 Aug 2004 03:55:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NAtIvw013313 for ; Mon, 23 Aug 2004 03:55:23 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so82388rnb for ; Mon, 23 Aug 2004 03:55:12 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr1196503rnh; Mon, 23 Aug 2004 03:55:12 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Mon, 23 Aug 2004 03:55:12 -0700 (PDT) Message-ID: <1f2ed5cd040823035518fe48ca@mail.gmail.com> Date: Mon, 23 Aug 2004 12:55:12 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: Atom WG In-Reply-To: <4127A649.7070603@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000c01c48791$7d01e3a0$6400a8c0@wyman.us> <1f2ed5cd0408211111548de5e@mail.gmail.com> <4127A649.7070603@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 21 Aug 2004 15:45:13 -0400, Sam Ruby wrote: > Danny Ayers wrote: > > > > I hate to bring this up, but this is exactly the kind of case the > > extensible version of would have been good for. I don't think > > Atom in its present form is capable of expressing the information in > > the RSS 1.0 feed in a non-lossy machine-readable way. > > For reference, here is the complete RSS 1.0 definition of the link > element[1]: > > The item's URL. Below is the example of the del.icio.us feed. You may note it contains considerably more than a simple element. That the rss:link element doesn't do much is irrelevant. The proposed extensible form of atom:link would have allowed something like: ... ... Cheers, Danny. - Heraclitus sayz (the Return of the Lo-Fi) http://heraclitussayz.blogspot.com/ Heraclitus sayz (the Return of the Lo-Fi) omit35 blog_mp3 music - - > [1] http://web.resource.org/rss/1.0/spec#s5.5.2 > > From owner-atom-syntax@mail.imc.org Mon Aug 23 09:12:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06811 for ; Mon, 23 Aug 2004 09:12:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ND10og047224; Mon, 23 Aug 2004 06:01:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ND10qQ047223; Mon, 23 Aug 2004 06:01:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ND0vcN047201 for ; Mon, 23 Aug 2004 06:00:58 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7ND0uuo028167; Mon, 23 Aug 2004 09:00:56 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOE43839 (AUTH bob@wyman.us); Mon, 23 Aug 2004 09:00:55 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Pier Fumagalli'" , "'Walter Underwood'" Cc: "'Atom Syntax'" Subject: RE: Syndication of updates and deletions of content Date: Mon, 23 Aug 2004 09:03:09 -0400 Message-ID: <001201c48911$8a5bd520$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal in-reply-to: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pier Fumagalli wrote: >On 20 Aug 2004, at 17:17, Walter Underwood wrote: >> When I was working with the search for ABCNews.com, they had >> permission to keep wire stories on their site for two weeks. After two >> weeks, they were deleted from the site. All the wire stories were >> deleted (always - always - always). > Deleted, or simply "locked away and they cannot go on the site anymore" Sites or organizations that work with wire services are often required to delete all content received after a short period of time. Contracts will often go to the extent of specifying that even copies on backup tapes must be erased. This is very traditional in the news business and makes sense if you consider the economic model for a wire story. Basically, a "fresh" news story and an "archival" news story are two distinct products and each has different prices, terms and conditions, etc. If you have an agreement to receive and distribute "fresh" news, the contract will often require that you delete any bits you received before those bits become useful as "archival" stories. In the past, many newspapers and even some wire services themselves had sold the rights to "archival" or "database" access to the content they created or distributed. Thus, in the past, you couldn't even get both rights from the same organization. You would typically buy "fresh" news rights from a syndicator while going to a different company and writing a second contract in order to buy "archival" access to exactly the same stories. bob wyman From owner-atom-syntax@mail.imc.org Mon Aug 23 09:26:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07576 for ; Mon, 23 Aug 2004 09:26:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NDIWOt052145; Mon, 23 Aug 2004 06:18:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NDIWtC052144; Mon, 23 Aug 2004 06:18:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NDIV5P052120 for ; Mon, 23 Aug 2004 06:18:32 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BzEiP-000645-AY; Mon, 23 Aug 2004 13:18:25 +0000 Message-ID: <4129EE9F.6040408@franklinmint.fm> Date: Mon, 23 Aug 2004 09:18:23 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pier Fumagalli CC: Walter Underwood , Atom Syntax Subject: Re: Syndication of updates and deletions of content References: <9C38CA5A-F23B-11D8-B4D3-000A95984AEA@betaversion.org> <412560AD.3030700@franklinmint.fm> <9CF4CE78-F281-11D8-B4D3-000A95984AEA@betaversion.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pier Fumagalli wrote: > > Deleted, or simply "locked away and they cannot go on the site anymore" > ??? Because we do the latter (embargo dates, like any other > publication), but that's far from getting rid of the content itself... The hypothetical Atom event probably wouldn't distinguish between the two cases. It would be the result of an http DELETE method. RFC2616 states that a successful DELETE signals that the server "...intends to delete the resource or move it to an inaccessible location."[0] Robert Sayre [0]http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7 From owner-atom-syntax@mail.imc.org Mon Aug 23 10:37:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12609 for ; Mon, 23 Aug 2004 10:37:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NETb6o072715; Mon, 23 Aug 2004 07:29:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NETbXO072714; Mon, 23 Aug 2004 07:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7NETZSp072658 for ; Mon, 23 Aug 2004 07:29:36 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 31777 invoked by uid 65534); 23 Aug 2004 14:29:27 -0000 Received: from pD9FF0804.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.8.4) by mail.gmx.net (mp019) with SMTP; 23 Aug 2004 16:29:27 +0200 X-Authenticated: #1915285 Message-ID: <4129FF40.5030702@gmx.de> Date: Mon, 23 Aug 2004 16:29:20 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom WG Subject: Re: ID wording References: <167BB9DC252A3C6BF7154507@diva.verity.com> <41270900.1020400@gmx.de> <41275A22.20008@intertwingly.net> In-Reply-To: <41275A22.20008@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Julian Reschke wrote: > >> >> There were *several* objections. Mine was: it doesn't make any sense >> to require "canonical" unless that buys us something. What does it buy >> us? > > > Here's why I voted against the first column in IDSurvey: > > http://www.imc.org/atom-syntax/mail-archive/msg08194.html > http://www.imc.org/atom-syntax/mail-archive/msg08229.html I just reread those mails and fail to understand the issue. If we state that atom IDs are strings, and are to be compared as strings, people who put them into URI objects (Tim's Java example) *and* use the objects' equality method simply make a programming mistake. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Mon Aug 23 10:43:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13024 for ; Mon, 23 Aug 2004 10:43:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NEZMQ8074686; Mon, 23 Aug 2004 07:35:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NEZLUs074685; Mon, 23 Aug 2004 07:35:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7NEZKXB074628 for ; Mon, 23 Aug 2004 07:35:21 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 32155 invoked by uid 65534); 23 Aug 2004 14:35:17 -0000 Received: from pD9FF0804.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.8.4) by mail.gmx.net (mp002) with SMTP; 23 Aug 2004 16:35:17 +0200 X-Authenticated: #1915285 Message-ID: <412A00A1.1060502@gmx.de> Date: Mon, 23 Aug 2004 16:35:13 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > > --On Saturday, August 21, 2004 10:29 AM +0200 Julian Reschke > wrote: > >> >> 1) There's a problem with that comparison. For instance, for timestamps >> comforming to IS08601, there's a well-defined way to parse them and to >> compare them as dates. There simply isn't a similar comparison method >> for URLs, unless you restrict yourself to generic URI syntax. > > > 2396bis, section 6. > > Yes. That chapter lists several comparison methods. Which one to use? >> 2) Again: *Which* comparison method would you prefer over char-by-char? > > > I did not say I preferred another method. I said that the spec > does not need to restrict implementations to char-by-char if > canonical URIs are required. That's incorrect. For instance, http://example.com and http://example:com:80 will compare equal for some comparison methods although they are both in canonical form. > Many libraries will provide an equals method for their URI objects, > and that is probably not char-by-char. Atom will require programmers > to avoid the obvious URI comparison routines and do something different. Yes. > Again, we require apples (URIs) and require that they be treated > as oranges (strings). > > If we require URIs, we should require good URI practices. Indeed. In fact, it's good practice to define which comparison to use because there are so many to choose from. Char-By-Char comparison is one of the comparison methods that qualifies. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Mon Aug 23 10:56:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14156 for ; Mon, 23 Aug 2004 10:56:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NEoHOR078922; Mon, 23 Aug 2004 07:50:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NEoHD6078921; Mon, 23 Aug 2004 07:50:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NEoGcx078902 for ; Mon, 23 Aug 2004 07:50:16 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7NEq9CJ006829; Mon, 23 Aug 2004 10:52:12 -0400 Message-ID: <412A0422.80404@intertwingly.net> Date: Mon, 23 Aug 2004 10:50:10 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> In-Reply-To: <412A00A1.1060502@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > >> I did not say I preferred another method. I said that the spec >> does not need to restrict implementations to char-by-char if >> canonical URIs are required. > > That's incorrect. For instance, > > http://example.com > > and > > http://example:com:80 > > will compare equal for some comparison methods although they are both in > canonical form. Assuming that the first colon in the second example is a typo, my reading of section 6.2.3 indicates that neither of the above URIs examples are expressed in the normal form for the "http" scheme. - Sam Ruby http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#normalize-scheme From owner-atom-syntax@mail.imc.org Mon Aug 23 11:46:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17521 for ; Mon, 23 Aug 2004 11:46:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NFWsQu091087; Mon, 23 Aug 2004 08:32:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NFWsYP091086; Mon, 23 Aug 2004 08:32:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NFWq6O091055 for ; Mon, 23 Aug 2004 08:32:54 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Mon, 23 Aug 2004 08:32:54 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: Next step on atom:id Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We have been discussing atom:id and have, I think, a good understanding of the alternatives. While there isn't currently strong consensus on which is better, it does seem likely that the differences in cost and effectiveness are minor. The survey at http://www.intertwingly.net/wiki/pie/IDSurvey is far from conclusive. Some folks on the list seem to hold tight to their views in particular directions even though there is near-universal agreement that atom:id is handy but not terribly important for most Atom users. Given this stickiness, it is probably not worthwhile for us to try to make another stab at this right now. Given that there are no other parts of the spec that are significantly affected by the syntax of atom:id, we can safely pick any of the current minorly-different proposals for the next draft. Thus, we will ask the format document authors to use http://www.intertwingly.net/wiki/pie/PaceIdConstruct (minus the requirement that atom:feed MUST contain an atom:id) as the text for atom:id and ask Sam to also put that pace on the "revisit" list. We will revisit the topic after everyone sees it in context; maybe that will help soften some of the firm views. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Aug 23 11:54:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18070 for ; Mon, 23 Aug 2004 11:54:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NFlXlm097438; Mon, 23 Aug 2004 08:47:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NFlXGL097437; Mon, 23 Aug 2004 08:47:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NFlWRj097427 for ; Mon, 23 Aug 2004 08:47:32 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7NFlX6k023044; Mon, 23 Aug 2004 11:47:34 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOE99812 (AUTH bob@wyman.us); Mon, 23 Aug 2004 11:47:32 -0400 (EDT) Message-Id: <200408231547.BOE99812@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Pier Fumagalli'" , Subject: RE: Syndication of updates and deletions of content Date: Mon, 23 Aug 2004 11:47:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Thread-Index: AcSEf2yLC7HOMBc8TMyUr1YmkkyTGgEpPTQg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pier Fumagalli wrote: > The one thing I find difficult when reading throughout the Syndication > Format specification is whether it allows the syndication of "deleted" > resources. I'm guessing that what Pier is looking for is some mechanism similar to that used in traditional professional syndication formats such as NewsML[1], NITF[2], etc. Those formats typically allow the communication of "deleted" as well as a number of other document states. For instance, NewsML provides a "status" element which supports the following states: * Usable -- The NewsItem and its content may be published without restriction. An item which is "usable" may transition to either "withheld" or "canceled" state. * Withheld -- Neither the NewsItem nor its content may be published until further notice. An item which is "withheld" can transition to "usable" or "cancelled" state. * Embargoed --- Neither the NewsItem nor its content may be published until released for publication by the provider at a certain point in time. An item which is "embargoed" can transition to "usable" or "canceled". * Canceled -- Neither the NewsItem nor its content may be used under any circumstances. If the NewsItem or its content has been published the publisher must take immediate action to withdraw or retract it, as may be legally necessary. Upon creation of a NewsItem, allowed values of the Status element are "Usable", "Withheld" and "Embargoed" but not "cancelled". NITF supports similar "states" with a different syntax. NewsML also provides a "StatusWillChange" element which provides advance notification of a status change that will occur automatically at some future date and time. For example, an item with a Status of "Embargoed" might have a StatusWillChange element stating that the status will become "Usable" at a specified time. This is equivalent to announcing in advance the time at which the embargo will end and the item will be released. For instance, the NewsML fragment below says that the current revision of the NewsItem, created on Aug 1 and last revised on Aug 24, has a status of "usable"; however, its state should automatically change to "cancelled" on 30 August 2004 at 19:12. 20040801T171000Z 20040824T113400Z Note: The "Scheme" attributes are provided to identify which "vocabulary" the FormalName comes from. bob wyman [1] http://www.newsml.org/pages/index.php [2] http://www.nitf.org/ From owner-atom-syntax@mail.imc.org Mon Aug 23 11:57:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18321 for ; Mon, 23 Aug 2004 11:57:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NFoldT098826; Mon, 23 Aug 2004 08:50:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NFolsO098825; Mon, 23 Aug 2004 08:50:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7NFok5k098772 for ; Mon, 23 Aug 2004 08:50:46 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 17364 invoked by uid 65534); 23 Aug 2004 15:50:43 -0000 Received: from pD9FF0804.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.8.4) by mail.gmx.net (mp008) with SMTP; 23 Aug 2004 17:50:43 +0200 X-Authenticated: #1915285 Message-ID: <412A124E.6050705@gmx.de> Date: Mon, 23 Aug 2004 17:50:38 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom WG Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> In-Reply-To: <412A0422.80404@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Julian Reschke wrote: > >> >>> I did not say I preferred another method. I said that the spec >>> does not need to restrict implementations to char-by-char if >>> canonical URIs are required. >> >> >> That's incorrect. For instance, >> >> http://example.com >> >> and >> >> http://example:com:80 >> >> will compare equal for some comparison methods although they are both >> in canonical form. > > > Assuming that the first colon in the second example is a typo, my Yes. > reading of section 6.2.3 indicates that neither of the above URIs > examples are expressed in the normal form for the "http" scheme. That's correct, but what does that have to do with the "canonical" form? And in case the spec would indeed require scheme-based normalization, how do you do that for a scheme you don't know? > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Mon Aug 23 12:50:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22492 for ; Mon, 23 Aug 2004 12:50:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NGbZ5e008451; Mon, 23 Aug 2004 09:37:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NGbZus008450; Mon, 23 Aug 2004 09:37:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NGbWeh008440 for ; Mon, 23 Aug 2004 09:37:32 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BzHp1-0005xn-Fe; Mon, 23 Aug 2004 16:37:27 +0000 Message-ID: <412A1D45.1070809@franklinmint.fm> Date: Mon, 23 Aug 2004 12:37:25 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Mark Pilgrim'" , "'Dare Obasanjo'" , "'Sam Ruby'" , "'Atom WG'" Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <200408212130.BOB20139@ms8.netsolmail.com> In-Reply-To: <200408212130.BOB20139@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > The example that I presented at the beginning of this thread > concerning del.icio.us, is instructive. Anil Dash has "solved" the > del.icio.us problem by 1) Violating the common understanding of the meaning > of "alternate" and by 2) Introducing the non-standard "rel='related'" to do > what most would have expected "alternate" to do. > Certainly, there are all sorts of creative solutions to problems > that can be achieved using Dash's methods or other hacks. However, such > hacks tend to harm interop in the long run even if they appear, by hiding an > issue, to solve problems in the near term. Just to be perfectly clear, I consider this a failure of the spec to provide a feature that RSS has. The RSS2 link element is vague/versatile enough to allow the behavior that Dash was after. What are some possible approaches for this feature? I can imagine an link. Also, does anyone feel that this feature is out of scope? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 23 13:44:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25559 for ; Mon, 23 Aug 2004 13:44:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHaj47016495; Mon, 23 Aug 2004 10:36:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NHajlg016494; Mon, 23 Aug 2004 10:36:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHainS016481; Mon, 23 Aug 2004 10:36:44 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail18.mac.com (webmail18-en1 [10.13.10.160]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7NHamfO012322; Mon, 23 Aug 2004 10:36:48 -0700 (PDT) Received: from webmail18 (localhost [127.0.0.1]) by webmail18.mac.com (8.12.6/8.12.2) with ESMTP id i7NHalJh013603; Mon, 23 Aug 2004 10:36:47 -0700 (PDT) Message-ID: <3262038.1093282607731.JavaMail.dtcd@mac.com> Date: Mon, 23 Aug 2004 13:36:47 -0400 From: Graham Parks To: Paul Hoffman / IMC Subject: Re: Next step on atom:id Cc: Atom WG in-reply-to: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, August 23, 2004, at 11:46AM, Paul Hoffman / IMC wrote: >Some folks on the list seem to hold tight to their views in >particular directions even though there is near-universal agreement >that atom:id is handy but not terribly important for most Atom users. Where the hell did you get that idea? atom:id is the most important thing in the fricking world as far as doing anything reliable or consistent with syndicated content is concerned. Many people on the list have said the same thing on several occasions. >Thus, we will ask the format document authors to use >http://www.intertwingly.net/wiki/pie/PaceIdConstruct (minus the >requirement that atom:feed MUST contain an atom:id) as the text for >atom:id and ask Sam to also put that pace on the "revisit" list. That Pace is remarkably clunky and ineloquent. Why not go with the current wording plus something about it being absolute? Graham From owner-atom-syntax@mail.imc.org Mon Aug 23 13:49:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25909 for ; Mon, 23 Aug 2004 13:49:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHg3f9017248; Mon, 23 Aug 2004 10:42:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NHg36t017247; Mon, 23 Aug 2004 10:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHg334017241 for ; Mon, 23 Aug 2004 10:42:03 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail18.mac.com (webmail18-en1 [10.13.10.160]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7NHg3ao007956; Mon, 23 Aug 2004 10:42:03 -0700 (PDT) Received: from webmail18 (localhost [127.0.0.1]) by webmail18.mac.com (8.12.6/8.12.2) with ESMTP id i7NHg3Jh013715; Mon, 23 Aug 2004 10:42:03 -0700 (PDT) Message-ID: <2111607.1093282923443.JavaMail.dtcd@mac.com> Date: Mon, 23 Aug 2004 13:42:03 -0400 From: Graham Parks To: mint@franklinmint.fm Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: bob@wyman.us, "'Mark Pilgrim'" , "'Dare Obasanjo'" , "'Sam Ruby'" , "'Atom WG'" in-reply-to: <412A1D45.1070809@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <200408212130.BOB20139@ms8.netsolmail.com> <412A1D45.1070809@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, August 23, 2004, at 12:50PM, Robert Sayre wrote: >Just to be perfectly clear, I consider this a failure of the spec to >provide a feature that RSS has. The RSS2 link element is vague/versatile >enough to allow the behavior that Dash was after. > >What are some possible approaches for this feature? I can imagine an > link. Mark Pilgrim's excellent proposal is here: http://www.xml.com/lpt/a/2004/06/16/dive.html Someone write a Pace. Shrook already supports related and via links*. Graham (* NB my objection to the tag syntax itself still stands, backed up by the convoluted code required to implement this feature) From owner-atom-syntax@mail.imc.org Mon Aug 23 13:54:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26301 for ; Mon, 23 Aug 2004 13:54:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHjOTn017713; Mon, 23 Aug 2004 10:45:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NHjO9d017712; Mon, 23 Aug 2004 10:45:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp3.afp.com (smtp3.afp.com [158.50.208.110]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHjLi8017677 for ; Mon, 23 Aug 2004 10:45:22 -0700 (PDT) (envelope-from laurent.lemeur@afp.com) Received: by smtp3.afp.com (Sendmail, from userid 1007) id 412AA46651; Mon, 23 Aug 2004 19:45:16 +0200 (CEST) Received: from alox.afp.com (unknown [158.50.165.141])by smtp3.afp.com (Sendmail) with ESMTPid 14EA546651; Mon, 23 Aug 2004 19:45:16 +0200 (CEST) Received: from sdtc05 (DELL-600.afp.local [158.50.208.176])by alox.afp.com (8.12.9/8.12.9) with ESMTP id i7NHiwt6029327;Mon, 23 Aug 2004 19:44:58 +0200 (METDST) From: "Laurent Le Meur" To: , "'Pier Fumagalli'" , Subject: RE : Syndication of updates and deletions of content Date: Mon, 23 Aug 2004 19:44:54 +0200 Message-ID: <018a01c48938$eaa37010$b0d0329e@afp.local> MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <200408231547.BOE99812@ms8.netsolmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7NHjMi8017696 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit If some of you want to have a better view at NewsML 1 and its "status" management (plus many existing features relative to some questions raised here), the IPTC has just released a new documentation (the "NewsML guidelines v1.0"), available at www.newsml.org (link on the right side, download the zip package). It goes deep in details about the standard, but in a more legible fashion than the original specification did. After reading, some of you may feel that NewsML is not so complicated after all, and that it could be worth trying something between Atom and the future NewsML 2 ;-). Laurent Le Meur AFP > -----Message d'origine----- > De : owner-atom-syntax@mail.imc.org [mailto:owner-atom- > syntax@mail.imc.org] De la part de Bob Wyman > Envoyé : lundi 23 août 2004 17:47 > À : 'Pier Fumagalli'; atom-syntax@imc.org > Objet : RE: Syndication of updates and deletions of content > > > Pier Fumagalli wrote: > > The one thing I find difficult when reading throughout the Syndication > > Format specification is whether it allows the syndication of "deleted" > > resources. > I'm guessing that what Pier is looking for is some mechanism > similar > to that used in traditional professional syndication formats such as > NewsML[1], NITF[2], etc. Those formats typically allow the communication > of > "deleted" as well as a number of other document states. > For instance, NewsML provides a "status" element which supports > the > following states: > * Usable -- The NewsItem and its content may be published without > restriction. An item which is "usable" may transition to either > "withheld" > or "canceled" state. > * Withheld -- Neither the NewsItem nor its content may be > published > until further notice. An item which is "withheld" can transition to > "usable" > or "cancelled" state. > * Embargoed --- Neither the NewsItem nor its content may be > published until released for publication by the provider at a certain > point > in time. An item which is "embargoed" can transition to "usable" or > "canceled". > * Canceled -- Neither the NewsItem nor its content may be used > under > any circumstances. If the NewsItem or its content has been published the > publisher must take immediate action to withdraw or retract it, as may > be > legally necessary. > Upon creation of a NewsItem, allowed values of the Status element > are "Usable", "Withheld" and "Embargoed" but not "cancelled". > NITF supports similar "states" with a different syntax. > > NewsML also provides a "StatusWillChange" element which provides > advance notification of a status change that will occur automatically at > some future date and time. For example, an item with a Status of > "Embargoed" > might have a StatusWillChange element stating that the status will > become > "Usable" at a specified time. This is equivalent to announcing in > advance > the time at which the embargo will end and the item will be released. > > For instance, the NewsML fragment below says that the current > revision of the NewsItem, created on Aug 1 and last revised on Aug 24, > has a > status of "usable"; however, its state should automatically change to > "cancelled" on 30 August 2004 at 19:12. > > > > FutureStatus="cancelled" Scheme="IptcStatus > DateAndTime="20040830T191200Z"/> > 20040801T171000Z > 20040824T113400Z > > > Note: The "Scheme" attributes are provided to identify which > "vocabulary" > the FormalName comes from. > > bob wyman > > [1] http://www.newsml.org/pages/index.php > [2] http://www.nitf.org/ > - AVERTISSEMENT Le présent mail et ses pièces jointes sont confidentiels et destinés au seul usage des personnes ou entités auxquelles ils sont adressés. Si vous avez reçu cet e-mail par erreur, veuillez contacter dans les plus brefs délais son expéditeur et effacer le contenu du message de votre système informatique. Toute divulgation, distribution ou copie de cet e-mail est strictement interdite. - DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please contact the sender and delete the email from your system. If you are not the named addressee you should not disseminate, distribute or copy this email. - From owner-atom-syntax@mail.imc.org Mon Aug 23 14:03:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26968 for ; Mon, 23 Aug 2004 14:03:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHumX0019084; Mon, 23 Aug 2004 10:56:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NHumlY019083; Mon, 23 Aug 2004 10:56:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NHumFo019077 for ; Mon, 23 Aug 2004 10:56:48 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BzJ3i-000151-Q2; Mon, 23 Aug 2004 17:56:42 +0000 Message-ID: <412A2FD9.40803@franklinmint.fm> Date: Mon, 23 Aug 2004 13:56:41 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: bob@wyman.us, "'Atom WG'" , Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <200408212130.BOB20139@ms8.netsolmail.com> <412A1D45.1070809@franklinmint.fm> <2111607.1093282923443.JavaMail.dtcd@mac.com> In-Reply-To: <2111607.1093282923443.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > > On Monday, August 23, 2004, at 12:50PM, Robert Sayre wrote: > > >>Just to be perfectly clear, I consider this a failure of the spec to >>provide a feature that RSS has. The RSS2 link element is vague/versatile >>enough to allow the behavior that Dash was after. >> >>What are some possible approaches for this feature? I can imagine an >> link. > > > Mark Pilgrim's excellent proposal is here: > http://www.xml.com/lpt/a/2004/06/16/dive.html > > Someone write a Pace. Shrook already supports related and via links*. > OK, there are old threads[0] about this. Some people (including myself) wanted a 'primary related'/'about' relation, so there would be a default link, if desired. How does that sit with aggregator authors? Seems like it would make life easier. Mark's sequence of 'related' links leans on ordering a little too much, doesn't you think? Robert Sayre > > (* NB my objection to the tag syntax itself still stands, backed up by the convoluted code required to implement this feature) oi... let's not go there right now. [0] http://www.imc.org/atom-syntax/mail-archive/msg05220.html From owner-atom-syntax@mail.imc.org Mon Aug 23 14:38:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29754 for ; Mon, 23 Aug 2004 14:38:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIVssA021596; Mon, 23 Aug 2004 11:31:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NIVsIK021595; Mon, 23 Aug 2004 11:31:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIVrvm021584 for ; Mon, 23 Aug 2004 11:31:54 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id 444EB171D26; Mon, 23 Aug 2004 14:31:52 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Graham Parks'" , "'Atom WG'" Subject: RE: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Date: Mon, 23 Aug 2004 14:31:23 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <2111607.1093282923443.JavaMail.dtcd@mac.com> Thread-Index: AcSJOIjUZ7PBRVc3SSGbh2WYshwTXAAArjOg Message-Id: <20040823183152.444EB171D26@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > Mark Pilgrim's excellent proposal is here: > http://www.xml.com/lpt/a/2004/06/16/dive.html > Someone write a Pace. Shrook already supports related and via links*. Even if everyone implemented what Mark has proposed, you still wouldn't necessarily get the behavior that Anil Dash achieves by switching his "alternate" and "related" links. What is missing from Mark's proposal is some indication of the relative significance or primacy of links. In the LinkBlog case, the entry is mere annotation and even if it has an alternate, that alternate is NOT the "interesting" bit. The interesting bit is the related link. However, in "normal" blogs, the "alternate" is the interesting bit and the related stuff is just that -- related... To get the behavior apparently sought by Anil, one would need to give the aggregator some sort of hint that said that the related link should be considered "primary" even though it wasn't the alternate. See the stuff below, copied from Anil's atom feed and modified to make the alternates and related links correct while adding a "primary='yes'" attribute to the related link. (Yes, I know its ugly. Read it for semantics -- not syntax.) - David Carlson's Online Timeline 2004-08-23T18:16:19Z 2004-08-23T13:15:50-05:00 tag:www.dashes.com,2004:/links//5.13842 2004-08-23T18:15:50Z a fascinating history of online systems, complete with screenshots - anildash http://anildash.com/ anil@dashes.com http://iml.jou.ufl.edu/carlson/timel ine.shtml... Of course, an alternative would be to do what NewsML does and that is to allow the "content" of an item to be specified by an URL rather than included in the entry. Also, like NewsML, provide for both a summary and the primary content itself. In NewsML, you might do something like: This is the summary... It talks about some other page. Note: Readers could be "taught" to display the summary in lists, but to open the "Main" entry when clicked on... I think this would do what Anil and others want. bob wyman From owner-atom-syntax@mail.imc.org Mon Aug 23 14:42:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00100 for ; Mon, 23 Aug 2004 14:42:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIYp1K021883; Mon, 23 Aug 2004 11:34:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NIYpcg021882; Mon, 23 Aug 2004 11:34:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIYpqq021864 for ; Mon, 23 Aug 2004 11:34:51 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so68981rnk for ; Mon, 23 Aug 2004 11:34:49 -0700 (PDT) Received: by 10.38.102.54 with SMTP id z54mr857496rnb; Mon, 23 Aug 2004 11:34:49 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Mon, 23 Aug 2004 11:34:49 -0700 (PDT) Message-ID: <14be96d304082311342346a9be@mail.gmail.com> Date: Mon, 23 Aug 2004 14:34:49 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Laurent Le Meur Subject: Re: RE : Syndication of updates and deletions of content Cc: bob@wyman.us, Pier Fumagalli , atom-syntax@imc.org In-Reply-To: <018a01c48938$eaa37010$b0d0329e@afp.local> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <018a01c48938$eaa37010$b0d0329e@afp.local> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 23 Aug 2004 19:44:54 +0200, Laurent Le Meur wrote: > If some of you want to have a better view at NewsML 1 and its "status" > management (plus many existing features relative to some questions raised > here), the IPTC has just released a new documentation (the "NewsML > guidelines v1.0"), available at www.newsml.org (link on the right side, > download the zip package). Let's see... an unlinkable announcement (without its own URI) of guidelines available only as a downloadable ZIP archive of a PDF file. I think we were kind of hoping for something more... of-the-web. But thanks for the pointer... or rather, the description of a pointer. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Mon Aug 23 14:49:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00525 for ; Mon, 23 Aug 2004 14:49:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIfEuS022384; Mon, 23 Aug 2004 11:41:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NIfEAo022383; Mon, 23 Aug 2004 11:41:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIfDj0022375 for ; Mon, 23 Aug 2004 11:41:14 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7NIfFhA008186 for ; Mon, 23 Aug 2004 14:41:15 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOF71458 (AUTH bob@wyman.us); Mon, 23 Aug 2004 14:41:10 -0400 (EDT) Message-Id: <200408231841.BOF71458@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom WG'" Subject: RE: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Date: Mon, 23 Aug 2004 14:40:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <2111607.1093282923443.JavaMail.dtcd@mac.com> Thread-Index: AcSJOIjUZ7PBRVc3SSGbh2WYshwTXAACBBCQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > Mark Pilgrim's excellent proposal is here: > http://www.xml.com/lpt/a/2004/06/16/dive.html > Someone write a Pace. Shrook already supports related and via links*. Even if everyone implemented what Mark has proposed, you still wouldn't necessarily get the behavior that Anil Dash achieves by switching his "alternate" and "related" links. What is missing from Mark's proposal is some indication of the relative significance or primacy of links. In the LinkBlog case, the entry is mere annotation and even if it has an alternate, that alternate is NOT the "interesting" bit. The interesting bit is the related link. However, in "normal" blogs, the "alternate" is the interesting bit and the related stuff is just that -- related... To get the behavior apparently sought by Anil, one would need to give the aggregator some sort of hint that said that the related link should be considered "primary" even though it wasn't the alternate. See the stuff below, copied from Anil's atom feed and modified to make the alternates and related links correct while adding a "primary='yes'" attribute to the related link. (Yes, I know its ugly. Read it for semantics -- not syntax.) - David Carlson's Online Timeline 2004-08-23T18:16:19Z 2004-08-23T13:15:50-05:00 tag:www.dashes.com,2004:/links//5.13842 2004-08-23T18:15:50Z a fascinating history of online systems, complete with screenshots - anildash http://anildash.com/ anil@dashes.com http://iml.jou.ufl.edu/carlson/timel ine.shtml... Of course, an alternative would be to do what NewsML does and that is to allow the "content" of an item to be specified by an URL rather than included in the entry. Also, like NewsML, provide for both a summary and the primary content itself. In NewsML, you might do something like: This is the summary... It talks about some other page. Note: Readers could be "taught" to display the summary in lists, but to open the "Main" entry when clicked on... I think this would do what Anil and others want. bob wyman From owner-atom-syntax@mail.imc.org Mon Aug 23 14:53:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00736 for ; Mon, 23 Aug 2004 14:53:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIlh94022799; Mon, 23 Aug 2004 11:47:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NIlhQ5022798; Mon, 23 Aug 2004 11:47:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIlgCG022791 for ; Mon, 23 Aug 2004 11:47:42 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3262038.1093282607731.JavaMail.dtcd@mac.com> References: <3262038.1093282607731.JavaMail.dtcd@mac.com> Date: Mon, 23 Aug 2004 11:47:41 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: Next step on atom:id Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:36 PM -0400 8/23/04, Graham Parks wrote: > >On Monday, August 23, 2004, at 11:46AM, Paul Hoffman / IMC > wrote: > >>Some folks on the list seem to hold tight to their views in >>particular directions even though there is near-universal agreement >>that atom:id is handy but not terribly important for most Atom users. > >Where the hell did you get that idea? atom:id is the most important >thing in the fricking world as far as doing anything reliable or >consistent with syndicated content is concerned. Many people on the >list have said the same thing on several occasions. My apologies for poor wording. I should have said the specific syntax rules about whether or not atom:id is canonicalized is not terribly important for most Atom users. > >Thus, we will ask the format document authors to use >>http://www.intertwingly.net/wiki/pie/PaceIdConstruct (minus the >>requirement that atom:feed MUST contain an atom:id) as the text for >>atom:id and ask Sam to also put that pace on the "revisit" list. > >That Pace is remarkably clunky and ineloquent. Why not go with the >current wording plus something about it being absolute? Are you proposing that because you saw consensus about that on the mailing list, or because it is your preference and you believe that more discussion now would be best for the WG? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Aug 23 15:03:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01340 for ; Mon, 23 Aug 2004 15:03:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NIum8j023426; Mon, 23 Aug 2004 11:56:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NIumdZ023425; Mon, 23 Aug 2004 11:56:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41208.mail.yahoo.com (web41208.mail.yahoo.com [66.218.93.41]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7NIumDd023413 for ; Mon, 23 Aug 2004 11:56:48 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040823185645.48181.qmail@web41208.mail.yahoo.com> Received: from [207.46.228.98] by web41208.mail.yahoo.com via HTTP; Mon, 23 Aug 2004 11:56:45 PDT Date: Mon, 23 Aug 2004 11:56:45 -0700 (PDT) From: Dare Obasanjo Subject: RE: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: bob@wyman.us, "'Atom WG'" In-Reply-To: <200408231841.BOF71458@ms8.netsolmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Bob Wyman wrote: > > Note: Readers could be "taught" to display the > summary in lists, but to open > the "Main" entry when clicked on... I think this > would do what Anil and > others want. Aggregators already do this today. If Anil's feed didn't have the bogus element then the behavior you'd see in RSS Bandit is exactly what you describe. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Mon Aug 23 15:24:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03905 for ; Mon, 23 Aug 2004 15:24:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NJHk8V025404; Mon, 23 Aug 2004 12:17:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NJHkUN025403; Mon, 23 Aug 2004 12:17:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NJHjeP025397 for ; Mon, 23 Aug 2004 12:17:45 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BzKK9-0005nv-Nd; Mon, 23 Aug 2004 19:17:45 +0000 Message-ID: <412A42D6.10200@franklinmint.fm> Date: Mon, 23 Aug 2004 15:17:42 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: bob@wyman.us, "'Atom WG'" Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <20040823185645.48181.qmail@web41208.mail.yahoo.com> In-Reply-To: <20040823185645.48181.qmail@web41208.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > --- Bob Wyman wrote: > >>Note: Readers could be "taught" to display the >>summary in lists, but to open >>the "Main" entry when clicked on... I think this >>would do what Anil and >>others want. > > > Aggregators already do this today. If Anil's feed > didn't have the bogus element then the > behavior you'd see in RSS Bandit is exactly what you > describe. > Let's look at Anil's feed again. If the following entry didn't have a bogus element, which link would RSS Bandit use as the "main" link, and which link is the actual alternate represention of the entry? Do you agree that this is broken? Robert Sayre technorati gets funded 2004-08-23T18:48:33Z 2004-08-23T13:48:33-05:00 tag:www.dashes.com,2004:/links//5.13844 2004-08-23T18:48:33Z appropriate that om got this scoop on a blog instead of a print mag anildash http://anildash.com/ anil@dashes.com http://www.gigaom.com/2004/08/technorati_gets.php... From owner-atom-syntax@mail.imc.org Mon Aug 23 15:41:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05373 for ; Mon, 23 Aug 2004 15:41:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NJYVHG026295; Mon, 23 Aug 2004 12:34:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NJYVZL026294; Mon, 23 Aug 2004 12:34:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7NJYOQx026280 for ; Mon, 23 Aug 2004 12:34:30 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040823193423.78611.qmail@web41205.mail.yahoo.com> Received: from [131.107.76.139] by web41205.mail.yahoo.com via HTTP; Mon, 23 Aug 2004 12:34:23 PDT Date: Mon, 23 Aug 2004 12:34:23 -0700 (PDT) From: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: mint@franklinmint.fm Cc: bob@wyman.us, "'Atom WG'" In-Reply-To: <412A42D6.10200@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Robert Sayre wrote: > > Let's look at Anil's feed again. If the following > entry didn't have a > bogus element, which link would RSS Bandit > use as the "main" > link, and which link is the actual alternate > represention of the entry? > Do you agree that this is broken? Nope. As a user of an aggregator reading a link blog I think the behavor is what I'd expect. Why would I want the main link my aggregator displayed be a link to Anil's blog instead of the link to the main item? Then it takes me two clicks to visit the linked item instead of one. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Mon Aug 23 15:46:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05598 for ; Mon, 23 Aug 2004 15:46:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NJee2M026637; Mon, 23 Aug 2004 12:40:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NJeevS026636; Mon, 23 Aug 2004 12:40:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NJedDu026630 for ; Mon, 23 Aug 2004 12:40:40 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BzKg2-0001P9-MM; Mon, 23 Aug 2004 19:40:22 +0000 Message-ID: <412A4825.80002@franklinmint.fm> Date: Mon, 23 Aug 2004 15:40:21 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: bob@wyman.us, "'Atom WG'" Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? References: <20040823193423.78611.qmail@web41205.mail.yahoo.com> In-Reply-To: <20040823193423.78611.qmail@web41205.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Robert Sayre wrote: > >>Let's look at Anil's feed again. If the following >>entry didn't have a >>bogus element, which link would RSS Bandit >>use as the "main" >>link, and which link is the actual alternate >>represention of the entry? >>Do you agree that this is broken? > > > Nope. As a user of an aggregator reading a link blog I > think the behavor is what I'd expect. Why would I want > the main link my aggregator displayed be a link to > Anil's blog instead of the link to the main item? Then > it takes me two clicks to visit the linked item > instead of one. OK, we agree with each other (I think...). I meant to ask if you think the format spec is broken. That link is not the alternate representation of the entry, but it is certainly the one that I want to click on. Wouldn't it be better if Anil could write Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 23 16:08:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06875 for ; Mon, 23 Aug 2004 16:08:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NK0B4G029403; Mon, 23 Aug 2004 13:00:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NK0BZt029401; Mon, 23 Aug 2004 13:00:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NK0Bi6029395 for ; Mon, 23 Aug 2004 13:00:11 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7NK0Fil009179 for ; Mon, 23 Aug 2004 14:00:15 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2X003HP0WEV7@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 23 Aug 2004 14:00:15 -0600 (MDT) Received: from [192.168.1.2] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2X00FRU0WE23@mail.sun.net> for atom-syntax@imc.org; Mon, 23 Aug 2004 14:00:14 -0600 (MDT) Date: Mon, 23 Aug 2004 13:00:29 -0700 From: Tim Bray Subject: Work Queue Rotation #6 To: Atom WG Message-id: <15216976-F53F-11D8-B845-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT http://www.intertwingly.net/wiki/pie/AtomPubIssuesList PaceDate - move to closed PaceIntrospection. This has received exactly zero commentary. In this case, I think it's unlikely that this means everyone agrees, since it's a fairly substantial and lightly-discussed piece of functionality. I'm inclined to interpret this as "the WG doesn't know what to do with this yet" and mark this one as revisit. If the revisit doesn't garner consensus, we should then mark it as closed. PacePostLocationMust. This looks like correction of an obvious oversight, we had one +1 and no further discussion. I suggest we mark "accepted" and ask Protocol draft editors to take it on board. PaceProvideSchema. I think we have strong consensus that there be Atom schemas in XSD and RNG, but that they not be normative, and we have people who are apparently willing to work on them and track the drafts. Let's mark this "Accepted" and it's the responsibility of the co-chairs/secretary to make sure that there are up-to-date schemas when we get close to 1.0. PaceWSDL. Well, this one (as Sam pointed out) is tied up with the shape our SOAP support takes. At least nobody shrieked "No WSDL." Back on the revisit list, I think. Time for Sam to turn the crank. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 23 16:39:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10585 for ; Mon, 23 Aug 2004 16:39:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKQU0Y031264; Mon, 23 Aug 2004 13:26:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NKQUcF031263; Mon, 23 Aug 2004 13:26:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKQU7X031251 for ; Mon, 23 Aug 2004 13:26:30 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7NKQWT8002180; Mon, 23 Aug 2004 16:26:34 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOG06653 (AUTH bob@wyman.us); Mon, 23 Aug 2004 16:26:26 -0400 (EDT) Message-Id: <200408232026.BOG06653@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Atom WG'" Subject: PaceProvideSchema -- Need ASN.1 Schema as well. Date: Mon, 23 Aug 2004 16:25:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <15216976-F53F-11D8-B845-000A95A51C9E@sun.com> Thread-Index: AcSJTiOLfwz5LiJCSzupLTes1YkxAgAAOZQA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > PaceProvideSchema. I think we have strong consensus that there be Atom > schemas in XSD and RNG, but that they not be normative, and we have > people who are apparently willing to work on them and track the drafts. I strongly believe that there should be an ASN.1 schema provided as well and I'm willing to do the work. ASN.1 is just as much an "XML Schema" language as the others are... bob wyman From owner-atom-syntax@mail.imc.org Mon Aug 23 16:58:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12948 for ; Mon, 23 Aug 2004 16:58:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKoXqF033382; Mon, 23 Aug 2004 13:50:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NKoXgf033381; Mon, 23 Aug 2004 13:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKoW8Y033368 for ; Mon, 23 Aug 2004 13:50:32 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 3583D7C2E9; Mon, 23 Aug 2004 23:41:38 +0200 (CEST) To: "Julian Reschke" Cc: Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> Message-ID: Date: Mon, 23 Aug 2004 22:52:50 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412A124E.6050705@gmx.de> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 23 Aug 2004 17:50:38 +0200, Julian Reschke wrote: > And in case the spec would indeed require scheme-based normalization, > how do you do that for a scheme you don't know? That's a good reason for requiring publishers to do the canonicalization and normalization (c14n11n :) and allowing consumers to compare atom:id char-by-char (as strings, not as URI's). -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Aug 23 18:26:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22577 for ; Mon, 23 Aug 2004 18:26:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NMFJAS041443; Mon, 23 Aug 2004 15:15:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NMFJID041442; Mon, 23 Aug 2004 15:15:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NMFI3A041431 for ; Mon, 23 Aug 2004 15:15:18 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so96468rnb for ; Mon, 23 Aug 2004 15:15:18 -0700 (PDT) Received: by 10.38.206.50 with SMTP id d50mr1410550rng; Mon, 23 Aug 2004 15:15:18 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Mon, 23 Aug 2004 15:15:18 -0700 (PDT) Message-ID: <1f2ed5cd04082315157a59dcc9@mail.gmail.com> Date: Tue, 24 Aug 2004 00:15:18 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: bob@wyman.us, Mark Pilgrim , Dare Obasanjo , Sam Ruby , Atom WG In-Reply-To: <412A1D45.1070809@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408212130.BOB20139@ms8.netsolmail.com> <412A1D45.1070809@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > The example that I presented at the beginning of this thread > > concerning del.icio.us, is instructive. Anil Dash has "solved" the > > del.icio.us problem by 1) Violating the common understanding of the meaning > > of "alternate" and by 2) Introducing the non-standard "rel='related'" to do > > what most would have expected "alternate" to do. > > Certainly, there are all sorts of creative solutions to problems > > that can be achieved using Dash's methods or other hacks. However, such > > hacks tend to harm interop in the long run even if they appear, by hiding an > > issue, to solve problems in the near term. > > Just to be perfectly clear, I consider this a failure of the spec to > provide a feature that RSS has. Agreed. The RSS2 link element is vague/versatile > enough to allow the behavior that Dash was after. I would suggest that versatile doesn't have to be vague and that actually supporting the behaviour is a different matter entirely. There are plenty of weaknesses in RSS 1.0, but it can express information like this unambiguously. Whether applications support the desired behaviour is another matter. Down the path of vagueness lies beauty such as HTML escaping in RSS2 descriptions. What puzzles me is how everyone seems to be of the opinion that quick-and-dirty hacks are unlikely to be useful long term, yet still prepared to build on the most fragile parts of existing systems. I would suggest that in this particular case a useful long term solution won't be found by hacking the feed to create behaviour to match the publisher's intent, but - well, errm - trying to get both ends to use a common format specification. In cases like this I would suggest that the feed itself should be entirely declarative with the data and leave it up to the consumer software/end user to determine the behaviour of the application. It's all very well basing a specification on established implementation, but building around particular bits of hackiness in particular tools is just likely to make things fragile. > What are some possible approaches for this feature? I can imagine an > link. Yes, that could well be useful. But there we're running into the conflict between an easily-managed small number of well-defined terms and the large number needed to support a wide range of scenarios. Either a choice has to be made between those two alternatives, or the nettle of extensibility has to be grasped. Atom may be coming along in places, but still a lot of it seems destined to inherit many of the worst features of each of its predecessors, and few of the good ones. Cheers, Danny. From owner-atom-syntax@mail.imc.org Mon Aug 23 18:45:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24085 for ; Mon, 23 Aug 2004 18:45:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NMc7CY043501; Mon, 23 Aug 2004 15:38:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NMc7jb043500; Mon, 23 Aug 2004 15:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7NMc7nU043454 for ; Mon, 23 Aug 2004 15:38:07 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040823223807.87830.qmail@web41209.mail.yahoo.com> Received: from [131.107.76.30] by web41209.mail.yahoo.com via HTTP; Mon, 23 Aug 2004 15:38:07 PDT Date: Mon, 23 Aug 2004 15:38:07 -0700 (PDT) From: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: Danny Ayers , mint@franklinmint.fm Cc: bob@wyman.us, Mark Pilgrim , Dare Obasanjo , Sam Ruby , Atom WG In-Reply-To: <1f2ed5cd04082315157a59dcc9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Danny Ayers wrote: > > Yes, that could well be useful. But there we're > running into the > conflict between an easily-managed small number of > well-defined terms > and the large number needed to support a wide range > of scenarios. > Either a choice has to be made between those two > alternatives, or the > nettle of extensibility has to be grasped. When all the issues with the so-called "extensibility" provided by link elements was being discussed I didn't see you propose any solutions. Do you have any now? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Mon Aug 23 21:33:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05641 for ; Mon, 23 Aug 2004 21:33:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O1Q1Kn056378; Mon, 23 Aug 2004 18:26:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O1Q1pR056377; Mon, 23 Aug 2004 18:26:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O1Q1td056364; Mon, 23 Aug 2004 18:26:01 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail19.mac.com (webmail19-en1 [10.13.10.174]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7O1Q6ro027883; Mon, 23 Aug 2004 18:26:06 -0700 (PDT) Received: from webmail19 (localhost [127.0.0.1]) by webmail19.mac.com (8.12.6/8.12.2) with ESMTP id i7O1Q6Za000384; Mon, 23 Aug 2004 18:26:06 -0700 (PDT) Message-ID: <14513705.1093310766519.JavaMail.dtcd@mac.com> Date: Mon, 23 Aug 2004 21:26:06 -0400 From: Graham Parks To: Paul Hoffman / IMC Subject: Re: Next step on atom:id Cc: atom-syntax@imc.org in-reply-to: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <3262038.1093282607731.JavaMail.dtcd@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, August 23, 2004, at 02:53PM, Paul Hoffman / IMC wrote: >My apologies for poor wording. I should have said the specific syntax >rules about whether or not atom:id is canonicalized is not terribly >important for most Atom users. Yes. Good. I'm glad that's what you meant. >Are you proposing that because you saw consensus about that on the >mailing list, or because it is your preference and you believe that >more discussion now would be best for the WG? PaceIDConstruct has lots of stuff that has never really been discussed - eg "If the identified resource is served dynamically, the content of an Identification construct MUST be created only once and then stored along with the resource". Also, (I've noticed) it's much easier to add things than it is to remove it later. We shouldn't be adding a big bunch of stuff there isn't consensus around, which is why I think it would be better to stick with the terse current version because Graham From owner-atom-syntax@mail.imc.org Mon Aug 23 21:57:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07360 for ; Mon, 23 Aug 2004 21:57:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O1i3gO057878; Mon, 23 Aug 2004 18:44:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O1i3Vm057877; Mon, 23 Aug 2004 18:44:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O1i2XF057869 for ; Mon, 23 Aug 2004 18:44:02 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail19.mac.com (webmail19-en1 [10.13.10.174]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7O1i92G012954; Mon, 23 Aug 2004 18:44:09 -0700 (PDT) Received: from webmail19 (localhost [127.0.0.1]) by webmail19.mac.com (8.12.6/8.12.2) with ESMTP id i7O1i8Za000755; Mon, 23 Aug 2004 18:44:08 -0700 (PDT) Message-ID: <9987500.1093311848625.JavaMail.dtcd@mac.com> Date: Mon, 23 Aug 2004 21:44:08 -0400 From: Graham Parks To: bobwyman@pubsub.com Subject: RE: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: atom-syntax@imc.org in-reply-to: <20040823183152.444EB171D26@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <20040823183152.444EB171D26@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, August 23, 2004, at 02:31PM, Bob Wyman wrote: > Even if everyone implemented what Mark has proposed, you still >wouldn't necessarily get the behavior that Anil Dash achieves by switching >his "alternate" and "related" links. What is missing from Mark's proposal is >some indication of the relative significance or primacy of links. In the >LinkBlog case, the entry is mere annotation and even if it has an alternate, >that alternate is NOT the "interesting" bit. The interesting bit is the >related link. However, in "normal" blogs, the "alternate" is the interesting >bit and the related stuff is just that -- related... To get the behavior >apparently sought by Anil, one would need to give the aggregator some sort >of hint that said that the related link should be considered "primary" even >though it wasn't the alternate. That's exactly the issue - that knowing the kind of link doesn't tell the aggregator where the user probably wants to go next. But I think you miss that in both cases the user knows where to go to next - they know if they're reading a link blog to look (in Shrook) in the related links box. The problem is that aggregators (including Shrook) that guessed that the user always wants to go to RSS's don't know that. There' an easy solution though. In Shrook there's currently a switch that toggles between showing the entry and the "alternate" link. There's no reason why it couldn't cycle through those two and the "related" links, or pop up a menu. It's a bit of extra hassle for the user, but it's only because of richer functionality. Graham From owner-atom-syntax@mail.imc.org Mon Aug 23 22:31:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09095 for ; Mon, 23 Aug 2004 22:31:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O2PYAJ060976; Mon, 23 Aug 2004 19:25:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O2PYdA060975; Mon, 23 Aug 2004 19:25:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O2PY4B060962; Mon, 23 Aug 2004 19:25:34 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7O2Peil007681; Mon, 23 Aug 2004 20:25:40 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2X003PRIQRV7@edgemail1.Central.Sun.COM>; Mon, 23 Aug 2004 20:25:40 -0600 (MDT) Received: from [192.168.1.100] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I2X00K7AIQR3N@mail.sun.net>; Mon, 23 Aug 2004 20:25:39 -0600 (MDT) Date: Mon, 23 Aug 2004 19:25:54 -0700 From: Tim Bray Subject: Re: Next step on atom:id In-reply-to: <14513705.1093310766519.JavaMail.dtcd@mac.com> To: Graham Parks Cc: Paul Hoffman / IMC , atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3262038.1093282607731.JavaMail.dtcd@mac.com> <14513705.1093310766519.JavaMail.dtcd@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 23, 2004, at 6:26 PM, Graham Parks wrote: > PaceIDConstruct has lots of stuff that has never really been discussed > - eg "If the identified resource is served dynamically, the content of > an Identification construct MUST be created only once and then stored > along with the resource". Hmm, I thought that one got lots of discussion, there was endless ranting about how atom:id was going to be broken because people would generate it dynamically, we must explain not to do that, etc... I thought there was a pretty clear mandate to go overboard in lecturing about the importance of persistence & immutability. Having said that, if you think you can improve the language making a suggestion for a delta is always OK. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 23 22:37:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09500 for ; Mon, 23 Aug 2004 22:37:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O2WWHR061433; Mon, 23 Aug 2004 19:32:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O2WWgK061432; Mon, 23 Aug 2004 19:32:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O2WVXM061426 for ; Mon, 23 Aug 2004 19:32:31 -0700 (PDT) (envelope-from distobj@acm.org) Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1BzR88-0004nC-00 for ; Mon, 23 Aug 2004 22:33:48 -0400 Date: Mon, 23 Aug 2004 22:33:48 -0400 To: Atom WG Subject: PaceWSDL Message-ID: <20040824023348.GS30868@markbaker.ca> References: <15216976-F53F-11D8-B845-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15216976-F53F-11D8-B845-000A95A51C9E@sun.com> User-Agent: Mutt/1.3.28i From: Mark Baker Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 23, 2004 at 01:00:29PM -0700, Tim Bray wrote: > PaceWSDL. Well, this one (as Sam pointed out) is tied up with the > shape our SOAP support takes. At least nobody shrieked "No WSDL." > Back on the revisit list, I think. Oops, I meant to do that earlier after waiting a few days to hear what others were saying. I'm -1 on PaceWSDL. Simply, I just see very little value in a WSDL description of the Atom protocol. The bulk of what the proposed WSDL communicates is just that "Atom operations are HTTP operations"; all the *in, *out, action URIs, etc.. is just a (very!) long winded way of saying that. WSDL 1.1 is, IMO, unsuitable for describing these kinds of (RESTful) services. And FWIW, WSDL 2.0 isn't much better (though it could have been if proposals by myself and Dave Orchard weren't rejected). FWIW, this doesn't mean I'm against using SOAP. Mark. From owner-atom-syntax@mail.imc.org Mon Aug 23 23:59:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13801 for ; Mon, 23 Aug 2004 23:59:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O3nVgm067771; Mon, 23 Aug 2004 20:49:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O3nVLK067770; Mon, 23 Aug 2004 20:49:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7O3nUq2067757 for ; Mon, 23 Aug 2004 20:49:30 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040824034932.96455.qmail@web41213.mail.yahoo.com> Received: from [131.107.76.143] by web41213.mail.yahoo.com via HTTP; Mon, 23 Aug 2004 20:49:32 PDT Date: Mon, 23 Aug 2004 20:49:32 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceWSDL To: Mark Baker , Atom WG In-Reply-To: <20040824023348.GS30868@markbaker.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Mark Baker wrote: > > Oops, I meant to do that earlier after waiting a few > days to hear what > others were saying. I'm -1 on PaceWSDL. > > Simply, I just see very little value in a WSDL > description of the Atom > protocol. I see a lot of value for developers on platforms that support XML Web Services such as the .NET Framework and Visual Studio.NET. > The bulk of what the proposed WSDL > communicates is just that > "Atom operations are HTTP operations"; all the *in, > *out, action URIs, > etc.. is just a (very!) long winded way of saying > that. WSDL 1.1 is, > IMO, unsuitable for describing these kinds of > (RESTful) services. And > FWIW, WSDL 2.0 isn't much better (though it could > have been if proposals > by myself and Dave Orchard weren't rejected). > > FWIW, this doesn't mean I'm against using SOAP. Besides religious objections to WSDL as a technology are there any technical reasons for voting -1 on PaceWSDL? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Tue Aug 24 02:10:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01103 for ; Tue, 24 Aug 2004 02:10:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O5v1b6079568; Mon, 23 Aug 2004 22:57:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O5v15F079567; Mon, 23 Aug 2004 22:57:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O5v1Hw079558 for ; Mon, 23 Aug 2004 22:57:01 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7O5v8ao028215; Mon, 23 Aug 2004 22:57:08 -0700 (PDT) Received: from [192.168.2.134] (65-102-148-169.tukw.qwest.net [65.102.148.169]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i7O5v7K5001531; Mon, 23 Aug 2004 22:57:08 -0700 (PDT) In-Reply-To: References: <3262038.1093282607731.JavaMail.dtcd@mac.com> <14513705.1093310766519.JavaMail.dtcd@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--944292762; protocol="application/pkcs7-signature" Message-Id: <6C7F6D02-F592-11D8-BE37-000A95DC3D90@mac.com> Cc: Atom WG From: Graham Subject: Re: Next step on atom:id Date: Mon, 23 Aug 2004 22:57:03 -0700 To: Tim Bray X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--944292762 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 23 Aug 2004, at 7:25 pm, Tim Bray wrote: > Hmm, I thought that one got lots of discussion, there was endless > ranting about how atom:id was going to be broken because people would > generate it dynamically, we must explain not to do that, etc... I > thought there was a pretty clear mandate to go overboard in lecturing > about the importance of persistence & immutability. I think people agree on the principle, it's just that the wording mandates how it MUST be implemented, and that's crossing a boundary - all we can dictate is how it must interoperate. The lecture needs to be non-normative, or at least not use capital letter words. > Having said that, if you think you can improve the language making a > suggestion for a delta is always OK. I'll draft something when I have time. Graham --Apple-Mail-2--944292762 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI0MDU1NzA0WjAjBgkqhkiG9w0BCQQxFgQUwLQLcCSEttwQVTAxu2hMCyOg oYwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAtfx9nFNZcr1DdjvWDlaJWjwh rUN/abT1fvUvFH49lv3F6VKJtT8X+V/PpXqD5X1lIRJULcNLnBYjUIigSE26B68uLQeRSK+KVqkW 9Je/tcyytbbseAXBJX9Stjud5J8HKTZbnR65mucRBIP5mUe+B4tXe/nf4XYHzX8mWh0jZtHU/Kfv FFvRHvKqvL8YOvSgOzvJWk+mBOD8+wy/ppoAuOt0c6YKVhp55714oNNXDqdOrXlTzGR+oCsFfGFH NAx+AZdMf9H4opgPkfGNUIM23OPEPkeVdolBxwu32Y54FY+Hr697Nw7MF7TxrsygkUFOnb7prZ1e oVnPmLxn4os1lwAAAAAAAA== --Apple-Mail-2--944292762-- From owner-atom-syntax@mail.imc.org Tue Aug 24 02:23:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05809 for ; Tue, 24 Aug 2004 02:23:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O6Fi98081649; Mon, 23 Aug 2004 23:15:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O6FiH0081648; Mon, 23 Aug 2004 23:15:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7O6Fg1c081636 for ; Mon, 23 Aug 2004 23:15:43 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 17898 invoked by uid 65534); 24 Aug 2004 06:15:44 -0000 Received: from pD9FF0875.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.8.117) by mail.gmx.net (mp006) with SMTP; 24 Aug 2004 08:15:44 +0200 X-Authenticated: #1915285 Message-ID: <412ADD0D.6020300@gmx.de> Date: Tue, 24 Aug 2004 08:15:41 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Mon, 23 Aug 2004 17:50:38 +0200, Julian Reschke > wrote: > >> And in case the spec would indeed require scheme-based normalization, >> how do you do that for a scheme you don't know? > > > That's a good reason for requiring publishers to do the > canonicalization and normalization (c14n11n :) and allowing consumers > to compare atom:id char-by-char (as strings, not as URI's). No, that's a good reason to require just char-by-char comparison. This is all that's needed, and therefore this is all the spec should say about this topic. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Aug 24 03:21:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09079 for ; Tue, 24 Aug 2004 03:21:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O7D3GO088141; Tue, 24 Aug 2004 00:13:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O7D3Pg088140; Tue, 24 Aug 2004 00:13:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O7D2sl088134 for ; Tue, 24 Aug 2004 00:13:02 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) by mail.mnot.net (Postfix) with ESMTP id 7C154727D; Tue, 24 Aug 2004 00:13:02 -0700 (PDT) In-Reply-To: <6C7F6D02-F592-11D8-BE37-000A95DC3D90@mac.com> References: <3262038.1093282607731.JavaMail.dtcd@mac.com> <14513705.1093310766519.JavaMail.dtcd@mac.com> <6C7F6D02-F592-11D8-BE37-000A95DC3D90@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <08FEEE33-F59D-11D8-82BE-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Next step on atom:id Date: Tue, 24 Aug 2004 00:13:01 -0700 To: Graham X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 - this is the gist of the problem I had with the text as well. On Aug 23, 2004, at 10:57 PM, Graham wrote: > I think people agree on the principle, it's just that the wording > mandates how it MUST be implemented, and that's crossing a boundary - > all we can dictate is how it must interoperate. The lecture needs to > be non-normative, or at least not use capital letter words. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 24 05:01:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16296 for ; Tue, 24 Aug 2004 05:01:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O8ktuZ001797; Tue, 24 Aug 2004 01:46:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O8ktKv001796; Tue, 24 Aug 2004 01:46:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7O8ksP2001756 for ; Tue, 24 Aug 2004 01:46:55 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 22240 messnum 5052643 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 24 Aug 2004 08:46:46 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail04.svc.cra.dublin.eircom.net (qp 22240) with SMTP; 24 Aug 2004 08:46:46 -0000 Message-ID: <412B0072.8030704@dehora.net> Date: Tue, 24 Aug 2004 09:46:42 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom WG Subject: Re: PaceWSDL References: <20040824034932.96455.qmail@web41213.mail.yahoo.com> In-Reply-To: <20040824034932.96455.qmail@web41213.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > Besides religious objections to WSDL as a technology > are there any technical reasons for voting -1 on > PaceWSDL? This looks like the same class of argument as the one for and against schemata. If we're going to be consistent in design the same rules we apply there will apply here. Breaking it down on technical/religious lines isn't helpful, it just encourages a flamefest. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 24 05:08:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16673 for ; Tue, 24 Aug 2004 05:08:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O8ko9x001780; Tue, 24 Aug 2004 01:46:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O8kofS001779; Tue, 24 Aug 2004 01:46:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp3.afp.com (smtp3.afp.com [158.50.208.110]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O8kmUG001719 for ; Tue, 24 Aug 2004 01:46:49 -0700 (PDT) (envelope-from laurent.lemeur@afp.com) Received: by smtp3.afp.com (Sendmail, from userid 1007) id 03B244646E; Tue, 24 Aug 2004 10:46:41 +0200 (CEST) Received: from alox.afp.com (unknown [158.50.165.141])by smtp3.afp.com (Sendmail) with ESMTPid DFCDA4641F; Tue, 24 Aug 2004 10:46:41 +0200 (CEST) Received: from sdtc05 ([158.50.180.103])by alox.afp.com (8.12.9/8.12.9) with ESMTP id i7O8kQt6010953;Tue, 24 Aug 2004 10:46:26 +0200 (METDST) From: "Laurent Le Meur" To: "'Bill de hÓra'" , "'Dan Brickley'" , "'Bill Kearney'" Cc: "'Atom-Syntax'" Subject: RE : Atom discussed at IPTC Annual General Meeting in Hong Kong, 25-28 June 2004 Date: Tue, 24 Aug 2004 10:46:31 +0200 Message-ID: <01df01c489b6$da6ee390$b0d0329e@afp.local> MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20040821102547.GB27163@homer.w3.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7O8knUG001774 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Maybe someone could let them know the work is happening at IETF? > Dan The IPTC meeting was in June, when the Atom WG and the W3C were discussing the matter. The move to the IETF has the same result. Atom still targets some part of the B2B news exchange (i.e. the main target for NewsML), even if it is "on the side", the main Atom target being "editing Web resources such as Weblogs, online journals, Wikis, and similar content". > All I can say is "and if you thing RDF is verbose..." > Bill Kearney Yes, NewsML 1 is verbose (it was the first shot, 4 years ago). The future NewsML 2 is something else, or so we hope. > If they or their members want to contribute to this WG, > they can show up here. > Bill de hÓra Thanks for the invitation. But it is not so easy, given the previous comment (any contribution from a news provider working outside of the blog domain can be easily discarded by the Atom WG, as the charters of the WGs are not equivalent). > The biggest problem with it [NewsML] seems to have been an inability to > say no to requirements. > Bill de hÓra Ok there are many. But 1/ B2B news exchange is not a tiny domain and 2/ a large set of requirements does not always mean a bulky structure. Here is the current draft for NewsML 2: http://www.newsml.org/dl.php?fn=NewsML/2.0-draft/specification/NewsML_2.0_sp ec_BusinessRequirements_14.pdf cheers Laurent Le Meur Agence France Presse IPTC member - AVERTISSEMENT Le présent mail et ses pièces jointes sont confidentiels et destinés au seul usage des personnes ou entités auxquelles ils sont adressés. Si vous avez reçu cet e-mail par erreur, veuillez contacter dans les plus brefs délais son expéditeur et effacer le contenu du message de votre système informatique. Toute divulgation, distribution ou copie de cet e-mail est strictement interdite. - DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please contact the sender and delete the email from your system. If you are not the named addressee you should not disseminate, distribute or copy this email. - From owner-atom-syntax@mail.imc.org Tue Aug 24 05:56:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19752 for ; Tue, 24 Aug 2004 05:56:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O9YGxq016410; Tue, 24 Aug 2004 02:34:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7O9YGNi016407; Tue, 24 Aug 2004 02:34:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7O9YFEU016371 for ; Tue, 24 Aug 2004 02:34:15 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so109292rnb for ; Tue, 24 Aug 2004 02:34:08 -0700 (PDT) Received: by 10.38.206.50 with SMTP id d50mr1584945rng; Tue, 24 Aug 2004 02:34:08 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Tue, 24 Aug 2004 02:34:08 -0700 (PDT) Message-ID: <1f2ed5cd04082402345e07d1b7@mail.gmail.com> Date: Tue, 24 Aug 2004 11:34:08 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: mint@franklinmint.fm, bob@wyman.us, Mark Pilgrim , Sam Ruby , Atom WG In-Reply-To: <20040823223807.87830.qmail@web41209.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040823223807.87830.qmail@web41209.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > When all the issues with the so-called "extensibility" > provided by link elements was being discussed I didn't > see you propose any solutions. Well I did, see: PaceLinkRelMechanism on the Wiki and http://dannyayers.com/2003/12/link.html > Do you have any now? QNames in attributes aren't something I'm a fan of, but as XHTML 2.0 appears set to include them then a variation of the technique above using them would seem a good pragmatic solution. Cheers, Danny. From owner-atom-syntax@mail.imc.org Tue Aug 24 07:27:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26209 for ; Tue, 24 Aug 2004 07:27:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OBHQOP041769; Tue, 24 Aug 2004 04:17:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OBHQ1F041761; Tue, 24 Aug 2004 04:17:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OBHPG7041751 for ; Tue, 24 Aug 2004 04:17:25 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7OBJPAb009881 for ; Tue, 24 Aug 2004 07:19:26 -0400 Message-ID: <412B23C4.9010602@intertwingly.net> Date: Tue, 24 Aug 2004 07:17:24 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: New AtomPubIssuesList for 2004/08/24 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit We're clearly beyond low hanging fruit territory now. First, I recommend for closure the following paces which have remained incomplete for an extended period of time (> 1 month): PaceFeedRefreshRate PaceNonHttpSoap PacePutToCreate PaceSiteMap The following are mostly independent issues which never have been formally scheduled, so let's discuss them now: PaceDigitalSignatures PaceErrVerb PaceEquivalents PaceItemLicense PaceReduceMustMay PaceServiceError PaceSimplifiedFeedFormat Looking ahead, we have Content, Person, Extensibility, and Versioning to discuss; then we need to make some final decisions on a number of topics: Date, ID, Introspection, Link, URI, Web services, Well Formed. My feeling is that if we complete this, the Format specification will be a a fairly good shape, the Protocol specification will still feel incomplete, and we won't have meaningfully tackled Archiving at all. If there is anything you feel is missing, please consider creating a Pace at this time. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 24 08:16:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29001 for ; Tue, 24 Aug 2004 08:16:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OC7hYg052314; Tue, 24 Aug 2004 05:07:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OC7hhu052313; Tue, 24 Aug 2004 05:07:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OC7hdC052269 for ; Tue, 24 Aug 2004 05:07:43 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 38783 invoked by uid 17064); 24 Aug 2004 12:07:34 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.9.151]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 24 Aug 2004 12:07:34 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200408210158.BNZ04687@ms8.netsolmail.com> References: <200408210158.BNZ04687@ms8.netsolmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <27E63092-F5C6-11D8-BAC6-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Atom discussed at IPTC Annual General Meeting in Hong Kong, 25-28 June 2004 Date: Tue, 24 Aug 2004 14:07:22 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I know I am going to get flamed and burned by the fanatical anti crowd out there, but someone has to. So might as well be me. :-( Some clever dude will probably then find a nice compromise way of putting things later. This is part of the extensibility debate going on here. Consider the set of physically possible worlds in which the following is true: - NewsML publishes their data structure as some OWL libraries - Atom is specified as an OWL library Of the above set of possibilities the following existential question is of interest: - are there worlds in which the NewsML library can be a seamlessly extension to the above specified Atom library, so that people who know Atom just need to learn some of the additional NewsML libraries, to be able to get the added functionality they want? In those worlds Atom would probably get out of the door much quicker, since any functionality that is part of NewsML would have a clear home to turn to. The value of the work of both groups would clearly be enhanced, to the benefit of all. Henry On 21 Aug 2004, at 03:59, Bob Wyman wrote: > Atom was discussed at the recent IPTC Standards Groups Annual > General Meeting. Some concern was expressed that Atom might be a > competitor > to NewsML... It would probably make sense for us to put some effort > into > figuring out how to work better with the IPTC. After all, based on > considerable experience in this field, they define the standards that > are > used by the traditional "news syndicators"... From owner-atom-syntax@mail.imc.org Tue Aug 24 09:16:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03320 for ; Tue, 24 Aug 2004 09:16:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OD2HEX064687; Tue, 24 Aug 2004 06:02:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OD2Hls064686; Tue, 24 Aug 2004 06:02:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OD2Gu9064666 for ; Tue, 24 Aug 2004 06:02:16 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so113459rnb for ; Tue, 24 Aug 2004 06:02:11 -0700 (PDT) Received: by 10.38.206.50 with SMTP id d50mr1636984rng; Tue, 24 Aug 2004 06:02:10 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Tue, 24 Aug 2004 06:02:10 -0700 (PDT) Message-ID: <1f2ed5cd0408240602179b8ce6@mail.gmail.com> Date: Tue, 24 Aug 2004 15:02:10 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Julian Reschke Subject: Re: ID wording Cc: "Asbjørn Ulsberg" , Atom-Syntax In-Reply-To: <412ADD0D.6020300@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think Paul's initial summary probably matches the consensus, and I for one could live with id as described, so +1. I wonder perhaps whether it might be worth formally defining a URIstring datatype in the Atom spec, as char-by-char comparison doesn't match the definition of equivalence for URIs, hence it's a different kind of thing. The canonicalization idea sounds good, but does seem like the introduction of something untried. Ok, so every HTTP server will incorporate some canonicalization subsystem, but moving this low-level stuff up a layer to Atom is a different story. So a SHOULD for it sounds reasonable. Cheers, Danny. From owner-atom-syntax@mail.imc.org Tue Aug 24 11:41:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15768 for ; Tue, 24 Aug 2004 11:41:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFQRmP096626; Tue, 24 Aug 2004 08:26:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OFQRIg096625; Tue, 24 Aug 2004 08:26:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFQRoT096591 for ; Tue, 24 Aug 2004 08:26:27 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id B454A171D23; Tue, 24 Aug 2004 11:26:24 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Graham'" , "'Tim Bray'" Cc: "'Atom WG'" Subject: RE: Next step on atom:id Date: Tue, 24 Aug 2004 11:24:23 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSJoaaJmNfrKY+KQW+YZYH/28bi2QATCaKQ in-reply-to: <6C7F6D02-F592-11D8-BE37-000A95DC3D90@mac.com> Message-Id: <20040824152624.B454A171D23@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > I think people agree on the principle, it's just that the wording > mandates how it MUST be implemented, and that's crossing a boundary > - all we can dictate is how it must interoperate. +1 IETF is about interoperation -- not implementation. You can require that something "appear to have been implemented" in some way, but you can't require that it *actually* be implemented in that way. What we define in IETF specifications is the form, interface, or externally visible behavior of systems -- not the methods by which the required behavior is implemented. An IETF spec says only: "Make it look like this!" How you meet that challenge is up to you. bob wyman From owner-atom-syntax@mail.imc.org Tue Aug 24 11:49:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16500 for ; Tue, 24 Aug 2004 11:49:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEaD0Q085091; Tue, 24 Aug 2004 07:36:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OEaDMk085090; Tue, 24 Aug 2004 07:36:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEa91R085078; Tue, 24 Aug 2004 07:36:10 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <01df01c489b6$da6ee390$b0d0329e@afp.local> References: <01df01c489b6$da6ee390$b0d0329e@afp.local> Date: Tue, 24 Aug 2004 07:34:51 -0700 To: "Laurent Le Meur" From: Paul Hoffman / IMC Subject: RE : Atom discussed at IPTC Annual General Meeting in Hong Kong, 25-28 June 2004 Cc: Atom WG Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 10:46 AM +0200 8/24/04, Laurent Le Meur wrote: > > If they or their members want to contribute to this WG, > > they can show up here. > > Bill de hÓra >Thanks for the invitation. But it is not so easy, given the previous comment >(any contribution from a news provider working outside of the blog domain >can be easily discarded by the Atom WG, as the charters of the WGs are not >equivalent). Any comment from anybody who comes from any community can be easily discarded or easily embraced in the Working Group. Both happen often; that's the advantage of open standards work. Anyone can come to the WG with proposals that might make it into the core, or discussions that might make good extensions. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 24 11:53:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16818 for ; Tue, 24 Aug 2004 11:53:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFcFCo099243; Tue, 24 Aug 2004 08:38:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OFcFlq099242; Tue, 24 Aug 2004 08:38:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFcEl1099221 for ; Tue, 24 Aug 2004 08:38:15 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7OFcBhA001133 for ; Tue, 24 Aug 2004 11:38:14 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOI40470 (AUTH bob@wyman.us); Tue, 24 Aug 2004 11:38:10 -0400 (EDT) Message-Id: <200408241538.BOI40470@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom WG'" Subject: PaceDigitalSignatures +1 (with comments) Date: Tue, 24 Aug 2004 11:36:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C489CE.8D79E220" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSJ8BPIAxvCGhBiQYOPhUp+zDh0YQ== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C489CE.8D79E220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Digital Signatures would be very, very useful in ensuring that we can validate the authenticity of entries that are included in aggregate/synthetic feeds or that are distributed individually by intermediaries over communications channels such as that provided by XMPP. (PubSub.com implements both methods.) There are many who have suggested that Atom or other syndication formats be relied on by businesses to communicate a wide variety of non-blog information (e.g. package shipment status, inventory levels, new product pricing announcements, etc.). It is likely that at least some businesses will not be comfortable making such "material statements" without a mechanism by which the authenticity of such statements can be determined. It is critical that it be possible to sign not only the Feed itself but also individual entries in the feed. Also, it should be possible to have a feed that contains entries signed by a variety of signers. bob wyman ------=_NextPart_000_0014_01C489CE.8D79E220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Digital Signatures would be = very, very useful in ensuring that we can validate the authenticity of entries = that are included in aggregate/synthetic feeds or that are distributed = individually by intermediaries over communications channels such as that provided by = XMPP. (PubSub.com implements both methods.)

There are many who have = suggested that Atom or other syndication formats be relied on by businesses to communicate a wide variety of non-blog information (e.g. package = shipment status, inventory levels, new product pricing announcements, etc.). It = is likely that at least some businesses will not be comfortable making such = “material statements” without a mechanism by which the authenticity of such = statements can be determined.

         =    It is critical that it be possible to sign not only the Feed itself but also individual entries in the feed. Also, it = should be possible to have a feed that contains entries signed by a variety of signers.

 

         =             &= nbsp;  bob wyman

 

------=_NextPart_000_0014_01C489CE.8D79E220-- From owner-atom-syntax@mail.imc.org Tue Aug 24 11:57:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17064 for ; Tue, 24 Aug 2004 11:57:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFnmcE002352; Tue, 24 Aug 2004 08:49:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OFnmFd002351; Tue, 24 Aug 2004 08:49:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFnlTM002314 for ; Tue, 24 Aug 2004 08:49:47 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so141047rnk for ; Tue, 24 Aug 2004 08:49:45 -0700 (PDT) Received: by 10.38.102.54 with SMTP id z54mr1243698rnb; Tue, 24 Aug 2004 08:49:45 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Tue, 24 Aug 2004 08:49:45 -0700 (PDT) Message-ID: <14be96d30408240849283699ca@mail.gmail.com> Date: Tue, 24 Aug 2004 11:49:45 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Dare Obasanjo Subject: Re: PaceWSDL Cc: Mark Baker , Atom WG In-Reply-To: <20040824034932.96455.qmail@web41213.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040824034932.96455.qmail@web41213.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 23 Aug 2004 20:49:32 -0700 (PDT), Dare Obasanjo wrote: > --- Mark Baker wrote: > > Simply, I just see very little value in a WSDL > > description of the Atom protocol. > > I see a lot of value for developers on platforms that > support XML Web Services such as the .NET Framework > and Visual Studio.NET. This from the person who implemented MSDN Web Services using print statements? http://www.kuro5hin.org/story/2003/9/4/122544/7625 > > The bulk of what the proposed WSDL > > communicates is just that > > "Atom operations are HTTP operations"; all the *in, > > *out, action URIs, > > etc.. is just a (very!) long winded way of saying > > that. WSDL 1.1 is, > > IMO, unsuitable for describing these kinds of > > (RESTful) services. And > > FWIW, WSDL 2.0 isn't much better (though it could > > have been if proposals > > by myself and Dave Orchard weren't rejected). > > > > FWIW, this doesn't mean I'm against using SOAP. > > Besides religious objections to WSDL as a technology > are there any technical reasons for voting -1 on > PaceWSDL? I don't see any religious objections in Mark's statement. I see a statement from an expert saying that WSDL simply doesn't bring very much to the table, due to limitations of WSDL. How is it religious simply because he understands enough about the limitations to have recommended improvements in the past? -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 24 12:01:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17356 for ; Tue, 24 Aug 2004 12:01:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEp3qe088563; Tue, 24 Aug 2004 07:51:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OEp30N088562; Tue, 24 Aug 2004 07:51:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEp21G088528 for ; Tue, 24 Aug 2004 07:51:03 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so75039rnk for ; Tue, 24 Aug 2004 07:50:53 -0700 (PDT) Received: by 10.38.72.72 with SMTP id u72mr1486916rna; Tue, 24 Aug 2004 07:50:53 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Tue, 24 Aug 2004 07:50:53 -0700 (PDT) Message-ID: <14be96d304082407503f45d5d0@mail.gmail.com> Date: Tue, 24 Aug 2004 10:50:53 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Atom WG Subject: PaceDigitalSignatures Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My concerns about PaceDigitalSignatures are detailed here: http://www.imc.org/atom-syntax/mail-archive/msg06963.html They got a +1 from Paul and no other discussion. If there are no other objections, I'll modify the Pace to include the restriction that signed content must not use an enveloping signature. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 24 12:10:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17907 for ; Tue, 24 Aug 2004 12:10:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEtnkq089721; Tue, 24 Aug 2004 07:55:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OEtn7x089720; Tue, 24 Aug 2004 07:55:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OEtkui089705 for ; Tue, 24 Aug 2004 07:55:48 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so75325rnk for ; Tue, 24 Aug 2004 07:55:49 -0700 (PDT) Received: by 10.38.92.30 with SMTP id p30mr1490046rnb; Tue, 24 Aug 2004 07:55:49 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Tue, 24 Aug 2004 07:55:49 -0700 (PDT) Message-ID: <14be96d3040824075565ef4da1@mail.gmail.com> Date: Tue, 24 Aug 2004 10:55:49 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Atom WG Subject: PaceEquivalents Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Several of the "equivalencies" listed in PaceEquivalents have been hotly contested in recent weeks, for example all of the date equivalencies. At a minimum, I think those 3 (issued, created, modified) should be removed from the list. I suspect that if we tried hard enough, we could argue the rest of these "equivalencies" into oblivion as well. No two terms mean exactly the same thing (sorry SemWeb fans). Instead of arguing them into oblivion, can someone give a good reason why to include any of them at all? What does this buy us? -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 24 12:22:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18694 for ; Tue, 24 Aug 2004 12:22:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OF7tdu092374; Tue, 24 Aug 2004 08:07:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OF7tcF092373; Tue, 24 Aug 2004 08:07:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OF7sca092335 for ; Tue, 24 Aug 2004 08:07:55 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so69674rnl for ; Tue, 24 Aug 2004 08:07:52 -0700 (PDT) Received: by 10.38.72.60 with SMTP id u60mr325480rna; Tue, 24 Aug 2004 08:07:52 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Tue, 24 Aug 2004 08:07:52 -0700 (PDT) Message-ID: <14be96d3040824080763a3c34@mail.gmail.com> Date: Tue, 24 Aug 2004 11:07:52 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Atom WG Subject: PaceSimplifiedFeedFormat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This appears to have been withdrawn by its author on June 7. Are there other advocates stepping up to support it, or are we simply closing it? -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 24 12:27:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19004 for ; Tue, 24 Aug 2004 12:27:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFBxG8093162; Tue, 24 Aug 2004 08:11:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OFBxvZ093161; Tue, 24 Aug 2004 08:11:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OFBw4j093152 for ; Tue, 24 Aug 2004 08:11:59 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so75884rnl for ; Tue, 24 Aug 2004 08:12:01 -0700 (PDT) Received: by 10.38.13.31 with SMTP id 31mr1494012rnm; Tue, 24 Aug 2004 08:12:01 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Tue, 24 Aug 2004 08:12:01 -0700 (PDT) Message-ID: <14be96d304082408125a4e04db@mail.gmail.com> Date: Tue, 24 Aug 2004 11:12:01 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Atom WG Subject: PaceReduceMustMay Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This "Pace" only lists two vague proposals: """ 1. First pass: de-emphasize RFC2119 imperatives where used for content models or markup syntax. 2. Second pass: rephrase for easier reading using a less formal tone. """ I'm all for #1, using RFC 2119 terminology correctly, but this Pace is utterly lacking in specifics. I'm against #2. This is not a junior high school essay; it's a specification. If you want to read a junior high school essay masquerading as a specification, I think we all know where to find one. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 24 12:29:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19250 for ; Tue, 24 Aug 2004 12:29:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OF1tZ4091153; Tue, 24 Aug 2004 08:01:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OF1thI091152; Tue, 24 Aug 2004 08:01:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OF1sNs091129 for ; Tue, 24 Aug 2004 08:01:54 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so69356rnl for ; Tue, 24 Aug 2004 08:01:51 -0700 (PDT) Received: by 10.38.72.60 with SMTP id u60mr323064rna; Tue, 24 Aug 2004 08:01:51 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Tue, 24 Aug 2004 08:01:51 -0700 (PDT) Message-ID: <14be96d3040824080140cc3f93@mail.gmail.com> Date: Tue, 24 Aug 2004 11:01:51 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Atom WG Subject: PaceItemLicense Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1. We already have entry-level element for human-readable copyright information. Precisely zero of our early adopters have been heard clamoring for machine-readable licensing information, so IMO it doesn't belong in the core. Let's shunt this one to an extension. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 24 12:55:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22223 for ; Tue, 24 Aug 2004 12:55:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGghSe014266; Tue, 24 Aug 2004 09:42:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OGghxq014261; Tue, 24 Aug 2004 09:42:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGggXe014163; Tue, 24 Aug 2004 09:42:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BzeNf-00062k-5Z; Tue, 24 Aug 2004 16:42:43 +0000 Message-ID: <412B6FFC.4040406@franklinmint.fm> Date: Tue, 24 Aug 2004 12:42:36 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax , Paul Hoffman / IMC Subject: DSig support in Aggregators Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit PaceDigitalSignatures: "Atom consumers MUST be able to parse XMLDSig content to extract the Atom content, even if they cannot do any signature validation. Atom consumers MUST NOT reject an Atom item simply because it is signed." Is this a reasonable demand to make? Could it be a SHOULD? Do any aggregators support this now? Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 24 13:02:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22775 for ; Tue, 24 Aug 2004 13:02:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGoMcR016235; Tue, 24 Aug 2004 09:50:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OGoMuM016234; Tue, 24 Aug 2004 09:50:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7OGoLvN016212 for ; Tue, 24 Aug 2004 09:50:21 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040824165017.73328.qmail@web41203.mail.yahoo.com> Received: from [207.46.238.137] by web41203.mail.yahoo.com via HTTP; Tue, 24 Aug 2004 09:50:17 PDT Date: Tue, 24 Aug 2004 09:50:17 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceWSDL To: Mark Pilgrim Cc: Mark Baker , Atom WG In-Reply-To: <14be96d30408240849283699ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Mark Pilgrim wrote: > > I don't see any religious objections in Mark's > statement. I see a > statement from an expert saying that WSDL simply > doesn't bring very > much to the table, due to limitations of WSDL. How > is it religious > simply because he understands enough about the > limitations to have > recommended improvements in the past? Argument from authority is no argument. If there are technical reasons there shouldn't be an informative WSDL in the spec I'd like to know them. Quite frankly, lots of people are going to create WSDLs for the Atom API (lots already have) and in the interest of interop I'd rather see them using the same WSDL that different ones which will all be slightly incompatible. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Tue Aug 24 13:14:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24213 for ; Tue, 24 Aug 2004 13:14:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGxqII018290; Tue, 24 Aug 2004 09:59:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OGxqKZ018289; Tue, 24 Aug 2004 09:59:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGxqZ5018282 for ; Tue, 24 Aug 2004 09:59:52 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7OGxttR028376 for ; Tue, 24 Aug 2004 09:59:55 -0700 (PDT) Received: from [192.168.2.134] (65-102-148-169.tukw.qwest.net [65.102.148.169]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i7OGxod2029679 for ; Tue, 24 Aug 2004 09:59:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <14be96d3040824080763a3c34@mail.gmail.com> References: <14be96d3040824080763a3c34@mail.gmail.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--904526583; protocol="application/pkcs7-signature" Message-Id: <02FCC40C-F5EF-11D8-BE37-000A95DC3D90@mac.com> From: Graham Subject: Re: PaceSimplifiedFeedFormat Date: Tue, 24 Aug 2004 09:59:50 -0700 To: Atom WG X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3--904526583 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 24 Aug 2004, at 8:07 am, Mark Pilgrim wrote: > This appears to have been withdrawn by its author on June 7. Are > there other advocates stepping up to support it, or are we simply > closing it? I'm still vaguely hopeful that having a feed that consists of references to separately fetched entries will happen (though not in v1.0). However, trying to make those references valid entries in themselves was never going to work, so close this. Graham --Apple-Mail-3--904526583 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI0MTY1OTUwWjAjBgkqhkiG9w0BCQQxFgQUoh0BHG/Zy0Zok8S3pnPUgE0y H0QweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAJbXZam3rwPOgzVX7Ud8eI/k4 xs2vH07buS+THNJ3oZ7RvQslmRPMcigrDPZZwMXUsdNw8lGnc3dRD30wGAkeqo/me2OdKn9oF1fp DZDR2UvIW9I5tl3Qxj2YjJpyN7elt9zDmlEDau/47O2SmV7pCd7IQi6Tinrtm5r5hOVJXu/TVlTW zYLIAMlbGcSAEDSXKgBR552qC+qeCIme5y4yowcOHaeQVVf6bQQ6BCO4fsgurpac7OtB8DNiX3/r rg2VCX4P+YfNp8sQtLb7t9AhIX/r4MCtlJ0CXvgdHrRVb8yEt7e4AIU1LmdKDlp7/LVV67fPCW7p 71njun1tKFZ8cgAAAAAAAA== --Apple-Mail-3--904526583-- From owner-atom-syntax@mail.imc.org Tue Aug 24 13:14:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24239 for ; Tue, 24 Aug 2004 13:14:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OH11mu018543; Tue, 24 Aug 2004 10:01:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OH11IB018531; Tue, 24 Aug 2004 10:01:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7OH10p5018492 for ; Tue, 24 Aug 2004 10:01:00 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040824170058.55667.qmail@web41207.mail.yahoo.com> Received: from [131.107.76.143] by web41207.mail.yahoo.com via HTTP; Tue, 24 Aug 2004 10:00:58 PDT Date: Tue, 24 Aug 2004 10:00:58 -0700 (PDT) From: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: Danny Ayers Cc: mint@franklinmint.fm, bob@wyman.us, Mark Pilgrim , Sam Ruby , Atom WG In-Reply-To: <1f2ed5cd04082402345e07d1b7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Danny Ayers wrote: > > When all the issues with the so-called > "extensibility" > > provided by link elements was being discussed I > didn't > > see you propose any solutions. > > Well I did, see: > > PaceLinkRelMechanism on the Wiki and > > http://dannyayers.com/2003/12/link.html > > > Do you have any now? > > QNames in attributes aren't something I'm a fan of, > but as XHTML 2.0 > appears set to include them then a variation of the > technique above > using them would seem a good pragmatic solution. I guess you missed the discussion on the list that pointed out that this isn't any more of an extensibility mechanism than just using namespaced elements since there is no uniform way to deal with elements? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 24 13:17:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24408 for ; Tue, 24 Aug 2004 13:17:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGwbPk017977; Tue, 24 Aug 2004 09:58:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OGwbVx017976; Tue, 24 Aug 2004 09:58:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGwZHr017965 for ; Tue, 24 Aug 2004 09:58:36 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <412B6FFC.4040406@franklinmint.fm> References: <412B6FFC.4040406@franklinmint.fm> Date: Tue, 24 Aug 2004 09:58:18 -0700 To: Atom Syntax From: Paul Hoffman / IMC Subject: Re: DSig support in Aggregators Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:42 PM -0400 8/24/04, Robert Sayre wrote: >PaceDigitalSignatures: >"Atom consumers MUST be able to parse XMLDSig content to extract the >Atom content, even if they cannot do any signature validation. Atom >consumers MUST NOT reject an Atom item simply because it is signed." > >Is this a reasonable demand to make? Yes. Parsing XMLDSig to find the Atom content is pretty trivial if you know know to parse XML at all, particularly if we do not allow signature enveloping (and, even better, if we pick a SHOULD for the style of signing). > Could it be a SHOULD? Sure, but then we would not have any interoperability for signed content. Remember, the person who is deciding whether or not to sign an entry has no idea who will eventually read it. This is the opposite of encrypting entries, which requires that the sender know which recipient can read it. If being able to read signed content is only a SHOULD, no one will sign anything unless they know they are in a closed environment. That will lead to the same mess we have in the email world. We have the opportunity to go well beyond that. >Do any aggregators support this now? Why is that relevant? We're writing a standard that is meant to be useful for decades in the future. Restricting it to features that already exist in pre-standards software hobbles it significantly. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 24 13:20:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24553 for ; Tue, 24 Aug 2004 13:20:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHCjpx021100; Tue, 24 Aug 2004 10:12:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHCj4d021099; Tue, 24 Aug 2004 10:12:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHChYC021087 for ; Tue, 24 Aug 2004 10:12:44 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <14be96d3040824080140cc3f93@mail.gmail.com> References: <14be96d3040824080140cc3f93@mail.gmail.com> Date: Tue, 24 Aug 2004 10:08:02 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: PaceItemLicense Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Having an entry whose semantics are intentionally undefined seems dangerous. Instead, anyone with a specific licensing scheme should write an extension. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 24 13:20:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24569 for ; Tue, 24 Aug 2004 13:20:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OH4mjd019300; Tue, 24 Aug 2004 10:04:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OH4mYl019298; Tue, 24 Aug 2004 10:04:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OH4kDr019288 for ; Tue, 24 Aug 2004 10:04:47 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <14be96d3040824075565ef4da1@mail.gmail.com> References: <14be96d3040824075565ef4da1@mail.gmail.com> Date: Tue, 24 Aug 2004 10:04:46 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: PaceEquivalents Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It is a very bad idea for a stable standard (which is what we intend for Atom) the equivalents to a document that is not finished (the FOAF work). It is also not clear why this should go in the Atom base spec. It would probably be much better if someone wanted to do a separate informational document on equivalents. In fact, this should be a set of documents, one for each external spec that is being pointed to. Getting Informational RFCs published is not that difficult. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 24 13:23:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24835 for ; Tue, 24 Aug 2004 13:23:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHF9S1021842; Tue, 24 Aug 2004 10:15:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHF9W3021838; Tue, 24 Aug 2004 10:15:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHF9RE021824; Tue, 24 Aug 2004 10:15:09 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7OHFAT8001506; Tue, 24 Aug 2004 13:15:10 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOI80313 (AUTH bob@wyman.us); Tue, 24 Aug 2004 13:15:08 -0400 (EDT) Message-Id: <200408241715.BOI80313@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: , "'Atom Syntax'" , "'Paul Hoffman / IMC'" Subject: RE: DSig support in Aggregators Date: Tue, 24 Aug 2004 13:13:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSJ/L7ajPnqqDvURAyzbIv8el5NmAAAGKzw in-reply-to: <412B6FFC.4040406@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > Is this a reasonable demand to make? Could it be a SHOULD? The problem here may be the wording -- not the intent. The Pace says: "Atom consumers MUST be able to parse XMLDSig content...". However, if we accept the limitation that no enveloping signatures are allowed, then the only real requirement is that consumers must be able to at least ignore the signatures. (Yes, this involves "parsing". However, it only requires XML parsing -- not any particular knowledge of XMLDSig.) It is reasonable to say that the mere presence of a signature, or other unrecognized XML content, should not cause an entry to be dropped. bob wyman From owner-atom-syntax@mail.imc.org Tue Aug 24 13:24:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24858 for ; Tue, 24 Aug 2004 13:24:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHCluF021114; Tue, 24 Aug 2004 10:12:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHCl5T021113; Tue, 24 Aug 2004 10:12:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHChYE021087 for ; Tue, 24 Aug 2004 10:12:46 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <14be96d304082408125a4e04db@mail.gmail.com> References: <14be96d304082408125a4e04db@mail.gmail.com> Date: Tue, 24 Aug 2004 10:12:08 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: PaceReduceMustMay Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This pace has two steps: >1. First pass: de-emphasize RFC2119 imperatives where used for content >models or markup syntax. >2. Second pass: rephrase for easier reading using a less formal tone. The first step is good. Protocol history in the IETF has shown the fewer requirements in the final spec, the more the actual requirements will stand out. The second step is very bad. We really, really want to follow RFC 2119 wording if we want this to be a standards-track RFC. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 24 13:37:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26768 for ; Tue, 24 Aug 2004 13:37:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHKwvV023142; Tue, 24 Aug 2004 10:20:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHKwqT023141; Tue, 24 Aug 2004 10:20:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHKw1T023134 for ; Tue, 24 Aug 2004 10:20:58 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7OHKuOo009502; Tue, 24 Aug 2004 10:21:00 -0700 (PDT) Received: from [192.168.2.134] (65-102-148-169.tukw.qwest.net [65.102.148.169]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i7OHKkK5006386; Tue, 24 Aug 2004 10:20:49 -0700 (PDT) In-Reply-To: <412B6FFC.4040406@franklinmint.fm> References: <412B6FFC.4040406@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--903271668; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: DSig support in Aggregators Date: Tue, 24 Aug 2004 10:20:44 -0700 To: mint@franklinmint.fm X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-4--903271668 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 24 Aug 2004, at 9:42 am, Robert Sayre wrote: > PaceDigitalSignatures: > "Atom consumers MUST be able to parse XMLDSig content to extract the > Atom content, even if they cannot do any signature validation. Atom > consumers MUST NOT reject an Atom item simply because it is signed." > > Is this a reasonable demand to make? Could it be a SHOULD? I don't know how easy is it? What do I have to do? I don't think it's reasonable to assume we all know, or we can have a decent discussion here if we all have to look it up. Graham --Apple-Mail-4--903271668 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI0MTcyMDQ1WjAjBgkqhkiG9w0BCQQxFgQU5fpbNEPUpqOu0hm4JVNxARIU RGwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAi65sX5rVK+dK5xf5Agt/VAT4 PucN0ZeBRIRFcSzd9ZH+5yAuMlUuadVtCJcT0YNqDHlBcOGl5KvLaE0016AarvOawvtHeHXrGd/9 Jm5XrWzkqBkaHygk5mRF6a446LEzp5YVQ2am3Q3xX+UeGJgToxvlJnRHPSWaC+fSc9FG9FN8D5bB +P40Lup/6ZAr1rx2HDppQ+5SYSyHOYZnD36XTya00Gc2xFLnjWDNU0HJZInpHJvRFtaYO4qpGsEo GokGQwtLbPJIc4uX9ardW4PxORLsXTiYsLqPYk/Se1sPfUrsf+EyjGMu6qBZJ9VCmThYm39l4Nkt Tb8C0WN/djFuFQAAAAAAAA== --Apple-Mail-4--903271668-- From owner-atom-syntax@mail.imc.org Tue Aug 24 13:37:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26792 for ; Tue, 24 Aug 2004 13:37:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHTLkm025265; Tue, 24 Aug 2004 10:29:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHTL6f025263; Tue, 24 Aug 2004 10:29:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHTKRU025207 for ; Tue, 24 Aug 2004 10:29:20 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so83702rnk for ; Tue, 24 Aug 2004 10:29:18 -0700 (PDT) Received: by 10.38.72.72 with SMTP id u72mr1553021rna; Tue, 24 Aug 2004 10:29:18 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Tue, 24 Aug 2004 10:29:18 -0700 (PDT) Message-ID: <14be96d3040824102942c700b0@mail.gmail.com> Date: Tue, 24 Aug 2004 13:29:18 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: bob@wyman.us Subject: Re: DSig support in Aggregators Cc: mint@franklinmint.fm, Atom Syntax , Paul Hoffman / IMC In-Reply-To: <200408241715.BOI80313@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408241715.BOI80313@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 24 Aug 2004 13:13:06 -0400, Bob Wyman wrote: > Robert Sayre wrote: > > Is this a reasonable demand to make? Could it be a SHOULD? > The problem here may be the wording -- not the intent. The Pace > says: "Atom consumers MUST be able to parse XMLDSig content...". However, if > we accept the limitation that no enveloping signatures are allowed, then the > only real requirement is that consumers must be able to at least ignore the > signatures. (Yes, this involves "parsing". However, it only requires XML > parsing -- not any particular knowledge of XMLDSig.) > It is reasonable to say that the mere presence of a signature, or > other unrecognized XML content, should not cause an entry to be dropped. Yes, this was my thinking for restricting it to non-enveloping signatures -- current aggregators already ignore stuff in random namespaces they don't understand, so a Signature element in the DSig namespace shouldn't pose a problem for existing clients that don't care about signed content. My original message spells this out in more detail, and has what I believe are syntactically correct examples: http://www.imc.org/atom-syntax/mail-archive/msg06963.html -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue Aug 24 13:57:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28362 for ; Tue, 24 Aug 2004 13:57:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHkcWS029185; Tue, 24 Aug 2004 10:46:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHkcxF029184; Tue, 24 Aug 2004 10:46:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHkbfx029175 for ; Tue, 24 Aug 2004 10:46:38 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so127147rnb for ; Tue, 24 Aug 2004 10:46:41 -0700 (PDT) Received: by 10.38.1.62 with SMTP id 62mr1757386rna; Tue, 24 Aug 2004 10:46:41 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Tue, 24 Aug 2004 10:46:41 -0700 (PDT) Message-ID: <1f2ed5cd04082410465f75ed3f@mail.gmail.com> Date: Tue, 24 Aug 2004 19:46:41 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: mint@franklinmint.fm, bob@wyman.us, Mark Pilgrim , Sam Ruby , Atom WG In-Reply-To: <20040824170058.55667.qmail@web41207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040824170058.55667.qmail@web41207.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I guess you missed the discussion on the list that > pointed out that this isn't any more of an > extensibility mechanism than just using namespaced > elements since there is no uniform way to deal with > elements? I did catch most of a related discussion, but haven't see anything to support what you're suggesting. The whole idea of defining elements in this way is to help deal with certain kinds of data uniformly. Using to denote an explicit relationship between the parent element/entity and another URI is a considerably narrower constraint than arbitrary (namespaced) elements and attributes that may appear anywhere with arbitrary semantics. By adding constraints, the chances of interoperability are increased. Cheers, Danny. From owner-atom-syntax@mail.imc.org Tue Aug 24 14:07:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29261 for ; Tue, 24 Aug 2004 14:07:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHvBtW031422; Tue, 24 Aug 2004 10:57:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHvB6i031421; Tue, 24 Aug 2004 10:57:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHukCX031326; Tue, 24 Aug 2004 10:56:47 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200408241715.BOI80313@ms8.netsolmail.com> References: <200408241715.BOI80313@ms8.netsolmail.com> Date: Tue, 24 Aug 2004 10:56:48 -0700 To: , , "'Atom Syntax'" From: Paul Hoffman / IMC Subject: RE: DSig support in Aggregators Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:13 PM -0400 8/24/04, Bob Wyman wrote: > It is reasonable to say that the mere presence of a signature, or >other unrecognized XML content, should not cause an entry to be dropped. Almost. The mere presence of a signature MUST NOT cause an entry to be dropped. Without that mandate, someone will drop them and claim conformance, and people will stop signing. This is a true interoperability issue. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 24 14:17:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29971 for ; Tue, 24 Aug 2004 14:17:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHx1Zd032110; Tue, 24 Aug 2004 10:59:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHx1SF032109; Tue, 24 Aug 2004 10:59:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHx0PQ032091; Tue, 24 Aug 2004 10:59:00 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BzfZV-0002bh-VJ; Tue, 24 Aug 2004 17:59:02 +0000 Message-ID: <412B81E0.3080507@franklinmint.fm> Date: Tue, 24 Aug 2004 13:58:56 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: bob@wyman.us, Atom Syntax , Paul Hoffman / IMC Subject: Re: DSig support in Aggregators References: <200408241715.BOI80313@ms8.netsolmail.com> <14be96d3040824102942c700b0@mail.gmail.com> In-Reply-To: <14be96d3040824102942c700b0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > On Tue, 24 Aug 2004 13:13:06 -0400, Bob Wyman wrote: >> However, if >>we accept the limitation that no enveloping signatures are allowed, then the >>only real requirement is that consumers must be able to at least ignore the >>signatures. > > Yes, this was my thinking for restricting it to non-enveloping > signatures... > > http://www.imc.org/atom-syntax/mail-archive/msg06963.html > Note that Paul (the Author) +1ed Mark's suggestion of disallowing enveloping signatures[0]. Paul, do you still agree? In order for this line of thinking to move forward, we need: * Revised spec text stating that "enveloped signatures are *not* OK", and possiblity recommending a signature style (enveloped, detached sibling, or detached external). * "a standard 'Atom-ish' way of linking to externally stored signatures" Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg07019.html From owner-atom-syntax@mail.imc.org Tue Aug 24 14:22:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00394 for ; Tue, 24 Aug 2004 14:21:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OI9nuE034637; Tue, 24 Aug 2004 11:09:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OI9nPl034635; Tue, 24 Aug 2004 11:09:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7OI9mW3034600 for ; Tue, 24 Aug 2004 11:09:48 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040824180942.27454.qmail@web41210.mail.yahoo.com> Received: from [131.107.76.139] by web41210.mail.yahoo.com via HTTP; Tue, 24 Aug 2004 11:09:42 PDT Date: Tue, 24 Aug 2004 11:09:42 -0700 (PDT) From: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: Danny Ayers Cc: mint@franklinmint.fm, bob@wyman.us, Mark Pilgrim , Sam Ruby , Atom WG In-Reply-To: <1f2ed5cd04082410465f75ed3f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Danny Ayers wrote: > > I guess you missed the discussion on the list that > > pointed out that this isn't any more of an > > extensibility mechanism than just using namespaced > > elements since there is no uniform way to deal > with > > elements? > > I did catch most of a related discussion, but > haven't see anything to > support what you're suggesting. The whole idea of > defining > elements in this way is to help deal with certain > kinds of data > uniformly. Using to denote an explicit > relationship between the > parent element/entity and another URI is a > considerably narrower > constraint than arbitrary (namespaced) elements and > attributes that > may appear anywhere with arbitrary semantics. By > adding constraints, > the chances of interoperability are increased. 1.) The various link elements proposed in Atom have arbitrary semantics. 2.) For links to provide a way to 'deal with certain kinds of certain kinds of data uniformly' you need to define these classes of data and how they should be treated. The last time this came up people balked at creating what was effectively a type system for links. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 24 15:00:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02984 for ; Tue, 24 Aug 2004 15:00:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OInnfF043933; Tue, 24 Aug 2004 11:49:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OInngG043932; Tue, 24 Aug 2004 11:49:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OInnmj043904 for ; Tue, 24 Aug 2004 11:49:49 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004082418494701600k1p9ke>; Tue, 24 Aug 2004 18:49:48 +0000 Date: Tue, 24 Aug 2004 12:49:47 -0600 Subject: Re: PaceDigitalSignatures Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <412B81E0.3080507@franklinmint.fm> Message-Id: <5F3EC3C4-F5FE-11D8-90DF-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Current text: "Atom consumers MUST be able to parse XMLDSig content to extract the Atom content, even if they cannot do any signature validation. Atom consumers MUST NOT reject an Atom item simply because it is signed." If restricting to non-enveloping signatures (+1 to that), perhaps this: "Atom consumers MAY ignore XMLDSig content, but MUST NOT reject an Atom item simply because it is signed." From owner-atom-syntax@mail.imc.org Tue Aug 24 15:08:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03728 for ; Tue, 24 Aug 2004 15:08:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIv9Hu045882; Tue, 24 Aug 2004 11:57:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OIv9pQ045881; Tue, 24 Aug 2004 11:57:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OIuw3r045839; Tue, 24 Aug 2004 11:56:59 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <412B81E0.3080507@franklinmint.fm> References: <200408241715.BOI80313@ms8.netsolmail.com> <14be96d3040824102942c700b0@mail.gmail.com> <412B81E0.3080507@franklinmint.fm> Date: Tue, 24 Aug 2004 11:56:52 -0700 To: mint@franklinmint.fm, Mark Pilgrim From: Paul Hoffman / IMC Subject: Re: DSig support in Aggregators Cc: bob@wyman.us, Atom Syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:58 PM -0400 8/24/04, Robert Sayre wrote: >Mark Pilgrim wrote: >>On Tue, 24 Aug 2004 13:13:06 -0400, Bob Wyman wrote: >>>However, if >>>we accept the limitation that no enveloping signatures are allowed, then the >>>only real requirement is that consumers must be able to at least ignore the >>>signatures. > >> >>Yes, this was my thinking for restricting it to non-enveloping >>signatures... >> >>http://www.imc.org/atom-syntax/mail-archive/msg06963.html >> > >Note that Paul (the Author) +1ed Mark's suggestion of disallowing >enveloping signatures[0]. Paul, do you still agree? Yes. My preference would have been to allow enveloping signatures, but Mark points out: - this is hard for some receivers - we have other choices >In order for this line of thinking to move forward, we need: > >* Revised spec text stating that "enveloped signatures are *not* >OK", and possiblity recommending a signature style (enveloped, >detached sibling, or detached external). >* "a standard 'Atom-ish' way of linking to externally stored signatures" Right. Do folks here have a preference between sibling or child signatures? My first thought is "child" for neatness, but that's a weak preference. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Aug 24 15:29:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05846 for ; Tue, 24 Aug 2004 15:28:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJLX4E049593; Tue, 24 Aug 2004 12:21:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OJLXC3049592; Tue, 24 Aug 2004 12:21:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJLX1p049579; Tue, 24 Aug 2004 12:21:33 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1BzgrN-0002JW-AC; Tue, 24 Aug 2004 19:21:33 +0000 Message-ID: <412B9537.7050702@franklinmint.fm> Date: Tue, 24 Aug 2004 15:21:27 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax CC: Paul Hoffman / IMC Subject: XMLEnc -- PaceDigitalSignatures Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just wanted to point out that PaceDigitalSignatures also contains requirements for XMLEnc[0]. The misleading name of the Pace is my fault--I renamed it when we accepted the protocol authentication aspects of the original PaceSecurityServices[1]. Robert Sayre [0] http://www.w3.org/TR/xmlenc-core/ [1] http://www.imc.org/atom-syntax/mail-archive/msg06996.html From owner-atom-syntax@mail.imc.org Tue Aug 24 15:36:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06346 for ; Tue, 24 Aug 2004 15:36:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJPs1f049851; Tue, 24 Aug 2004 12:25:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OJPsUF049850; Tue, 24 Aug 2004 12:25:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7OJPrkv049828 for ; Tue, 24 Aug 2004 12:25:53 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 5570 invoked from network); 24 Aug 2004 19:31:42 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 24 Aug 2004 19:31:42 -0000 Subject: Re: DSig support in Aggregators From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Paul Hoffman / IMC Cc: mint@franklinmint.fm, Mark Pilgrim , bob@wyman.us, Atom syntax In-Reply-To: References: <200408241715.BOI80313@ms8.netsolmail.com> <14be96d3040824102942c700b0@mail.gmail.com> <412B81E0.3080507@franklinmint.fm> Content-Type: text/plain Message-Id: <1093375642.2517.71.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 24 Aug 2004 20:27:22 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-08-24 at 19:56, Paul Hoffman / IMC wrote: > Right. Do folks here have a preference between sibling or child > signatures? My first thought is "child" for neatness, but that's a > weak preference. Child, of the item being signed, but optional please. -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Tue Aug 24 15:51:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07217 for ; Tue, 24 Aug 2004 15:51:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJdInn051143; Tue, 24 Aug 2004 12:39:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OJdIfV051142; Tue, 24 Aug 2004 12:39:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJdG43051122 for ; Tue, 24 Aug 2004 12:39:17 -0700 (PDT) (envelope-from ga-atom-syntax@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bzh8W-0005b9-00 for ; Tue, 24 Aug 2004 21:39:16 +0200 Received: from corp-fw-main.jabber.com ([207.182.164.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Aug 2004 21:39:16 +0200 Received: from stpeter by corp-fw-main.jabber.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Aug 2004 21:39:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Peter Saint-Andre Subject: Re: Syndication of updates and deletions of content Date: Tue, 24 Aug 2004 13:39:17 -0600 Organization: Jabber Software Foundation Lines: 25 Message-ID: References: <200408231547.BOE99812@ms8.netsolmail.com> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: corp-fw-main.jabber.com User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In article <200408231547.BOE99812@ms8.netsolmail.com>, "Bob Wyman" wrote: > Pier Fumagalli wrote: > > The one thing I find difficult when reading throughout the Syndication > > Format specification is whether it allows the syndication of "deleted" > > resources. > I'm guessing that what Pier is looking for is some mechanism similar > to that used in traditional professional syndication formats such as > NewsML[1], NITF[2], etc. Those formats typically allow the communication of > "deleted" as well as a number of other document states. Joe Hildebrand and I have written an individual submission that describes methods for sending and receiving Atom notifications via the Extensible Messaging and Presence Protocol (XMPP): http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-00.tx t TinyURL: http://tinyurl.com/4qlbq It may be of interest to those looking for notifications related to the creation, modification, and deletion of Atom entries. Peter From owner-atom-syntax@mail.imc.org Tue Aug 24 18:09:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16430 for ; Tue, 24 Aug 2004 18:09:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLrvNa062309; Tue, 24 Aug 2004 14:53:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OLrvFc062308; Tue, 24 Aug 2004 14:53:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLrt9H062266; Tue, 24 Aug 2004 14:53:55 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id 453F3171D24; Tue, 24 Aug 2004 17:53:50 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Paul Hoffman / IMC'" , , "'Mark Pilgrim'" Cc: , "'Atom Syntax'" Subject: RE: DSig support in Aggregators Date: Tue, 24 Aug 2004 17:51:49 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSKDC89L6Gh0nWXQOqe5ND+E8rJpwAGByRA in-reply-to: Message-Id: <20040824215350.453F3171D24@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > Right. Do folks here have a preference between sibling or child > signatures? My first thought is "child" for neatness, but that's > a weak preference. +1 for child, not sibling. Neatness is important... After all, as many children know: "Cleanliness is next to Godliness..." bob wyman From owner-atom-syntax@mail.imc.org Tue Aug 24 18:35:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19618 for ; Tue, 24 Aug 2004 18:35:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OMRChb069842; Tue, 24 Aug 2004 15:27:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OMRCvX069841; Tue, 24 Aug 2004 15:27:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OMRBE0069834 for ; Tue, 24 Aug 2004 15:27:12 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7OMRG4g007628; Tue, 24 Aug 2004 18:27:16 -0400 Message-ID: <412BC0C3.20407@intertwingly.net> Date: Tue, 24 Aug 2004 18:27:15 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: atom-syntax@imc.org Subject: Transporting Atom Notifications over the XMPP (was: updates and deletes) References: <200408231547.BOE99812@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Peter Saint-Andre wrote: > > Joe Hildebrand and I have written an individual submission that > describes methods for sending and receiving Atom notifications via the > Extensible Messaging and Presence Protocol (XMPP): > > http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-00.tx > t > > TinyURL: http://tinyurl.com/4qlbq > > It may be of interest to those looking for notifications related to the > creation, modification, and deletion of Atom entries. Do you have any thoughts on how pubsub:id (a.k.a. ItemIDs) should (or should not) relate to atom:id elements in atom:entry elements contained within such notifications? What are the plans for JEP-0060? http://www.jabber.org/jeps/jep-0060.html - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 24 18:46:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20164 for ; Tue, 24 Aug 2004 18:46:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OMcvdO071980; Tue, 24 Aug 2004 15:38:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OMcvu8071979; Tue, 24 Aug 2004 15:38:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OMcu3p071970 for ; Tue, 24 Aug 2004 15:38:56 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7OMd1bb008160; Tue, 24 Aug 2004 18:39:01 -0400 Message-ID: <412BC384.70902@intertwingly.net> Date: Tue, 24 Aug 2004 18:39:00 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Atom WG Subject: Re: PaceWSDL References: <20040824165017.73328.qmail@web41203.mail.yahoo.com> In-Reply-To: <20040824165017.73328.qmail@web41203.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > Quite frankly, > lots of people are going to create WSDLs for the Atom > API (lots already have) and in the interest of interop > I'd rather see them using the same WSDL that different > ones which will all be slightly incompatible. What should be included in the spec? WSDL 1.1? WSDL 2.0? Both? - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 24 19:26:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22853 for ; Tue, 24 Aug 2004 19:26:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ONIRKe078994; Tue, 24 Aug 2004 16:18:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ONIRMB078993; Tue, 24 Aug 2004 16:18:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ONIRRF078986 for ; Tue, 24 Aug 2004 16:18:27 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so141357rnb for ; Tue, 24 Aug 2004 16:18:32 -0700 (PDT) Received: by 10.38.206.50 with SMTP id d50mr1871079rng; Tue, 24 Aug 2004 16:18:32 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Tue, 24 Aug 2004 16:18:32 -0700 (PDT) Message-ID: <1f2ed5cd04082416182084e284@mail.gmail.com> Date: Wed, 25 Aug 2004 01:18:32 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: mint@franklinmint.fm, bob@wyman.us, Mark Pilgrim , Sam Ruby , Atom WG In-Reply-To: <20040824180942.27454.qmail@web41210.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040824180942.27454.qmail@web41210.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 24 Aug 2004 11:09:42 -0700 (PDT), Dare Obasanjo wrote: > > > > --- Danny Ayers wrote: > > > I guess you missed the discussion on the list that > > > pointed out that this isn't any more of an > > > extensibility mechanism than just using namespaced > > > elements since there is no uniform way to deal > > with > > > elements? > > > > I did catch most of a related discussion, but > > haven't see anything to > > support what you're suggesting. The whole idea of > > defining > > elements in this way is to help deal with certain > > kinds of data > > uniformly. Using to denote an explicit > > relationship between the > > parent element/entity and another URI is a > > considerably narrower > > constraint than arbitrary (namespaced) elements and > > attributes that > > may appear anywhere with arbitrary semantics. By > > adding constraints, > > the chances of interoperability are increased. > > 1.) The various link elements proposed in Atom have > arbitrary semantics. Not entirely, there are quite a number of constraints. They express a binary relationship between two unambiguously defined entities. The relationship is directional and defined by the value of the rel attribute. This, on top of the disambiguation of namespace qualification offers a mechanism which is versatile without being vague. > 2.) For links to provide a way to 'deal with certain > kinds of certain kinds of data uniformly' you need to > define these classes of data and how they should be > treated. The last time this came up people balked at > creating what was effectively a type system for links. I wouldn't personally have described it as a type system for the links, more for the parent & child entities involved, building on the typing of elements in the core spec. But whatever you prefer to call it it's potentially useful. If people want to balk that's entirely up to them. I don't myself think the link mechanism is perfect, not even adequate. But at the moment the other alternatives are either limiting the applicability of Atom (by restricting things to core terms) or allowing anything anywhere (with namespaces) and introducing a barrier to interop. Cheers, Danny. From owner-atom-syntax@mail.imc.org Tue Aug 24 20:17:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26305 for ; Tue, 24 Aug 2004 20:17:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P0BMB2084849; Tue, 24 Aug 2004 17:11:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P0BMuS084848; Tue, 24 Aug 2004 17:11:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7P0BLs2084833 for ; Tue, 24 Aug 2004 17:11:21 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825001122.21484.qmail@web41215.mail.yahoo.com> Received: from [131.107.76.139] by web41215.mail.yahoo.com via HTTP; Tue, 24 Aug 2004 17:11:22 PDT Date: Tue, 24 Aug 2004 17:11:22 -0700 (PDT) From: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: Danny Ayers Cc: mint@franklinmint.fm, bob@wyman.us, Mark Pilgrim , Sam Ruby , Atom WG In-Reply-To: <1f2ed5cd04082416182084e284@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Danny Ayers wrote: > > > > > 1.) The various link elements proposed in Atom > have > > arbitrary semantics. > > Not entirely, there are quite a number of > constraints. They express a > binary relationship between two unambiguously > defined entities. The > relationship is directional and defined by the value > of the rel > attribute. This, on top of the disambiguation of > namespace > qualification offers a mechanism which is versatile > without being > vague. To consumers of Atom feeds they have arbitrary semantics. It seems you are confusing uniform syntax with uniform semantics. According to the current draft specs a link could mean (1) users can click here to see human readable content related to the entry (2) the URI to send HTTP requests using a variety of methods [DELETE, POST, PUT, GET] to interact with the entry (3) a link to an Atom feed that contains entries that are related to this one in some linear sequence. These are pretty arbitrary semantics only connected by the fact they share uniform syntax. Considering all the various proposals for potential link elements that have shown up it is even more clear that if such an "extensibility" mechanism was chosen there would be little connection between the semantics or aggregator behavior on consuming these links besides uniform syntax. > I don't myself think the link mechanism is perfect, > not even adequate. > But at the moment the other alternatives are either > limiting the > applicability of Atom (by restricting things to core > terms) or > allowing anything anywhere (with namespaces) and > introducing a barrier > to interop. You're kidding right? How is seeing an entry with any different from seeing the same one with ftp://www.example.com/pool.js What exactly makes the former a recipe for interoperability and the latter a barrier? Do you seriously think that the fact that one could render the latter in the browser as a clickable link somehow makes it more useful than the latter? If so do you think the same about rel="service.post" and rel="service.edit"? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 24 20:18:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26367 for ; Tue, 24 Aug 2004 20:18:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P0CfPo085022; Tue, 24 Aug 2004 17:12:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P0Cf6C085021; Tue, 24 Aug 2004 17:12:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7P0Ce1O084992 for ; Tue, 24 Aug 2004 17:12:40 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825001241.70541.qmail@web41202.mail.yahoo.com> Received: from [207.46.228.98] by web41202.mail.yahoo.com via HTTP; Tue, 24 Aug 2004 17:12:41 PDT Date: Tue, 24 Aug 2004 17:12:41 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceWSDL To: Sam Ruby Cc: Atom WG In-Reply-To: <412BC384.70902@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Sam Ruby wrote: > > > Quite frankly, > > lots of people are going to create WSDLs for the > Atom > > API (lots already have) and in the interest of > interop > > I'd rather see them using the same WSDL that > different > > ones which will all be slightly incompatible. > > What should be included in the spec? WSDL 1.1? > WSDL 2.0? Both? I'd prefer WSDL 1.1 since WSDL 2.0 isn't done and I suspect it won't be done before Atom is completed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 24 20:45:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27966 for ; Tue, 24 Aug 2004 20:45:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P0bn3F087330; Tue, 24 Aug 2004 17:37:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P0bnIe087329; Tue, 24 Aug 2004 17:37:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7P0bm5R087314 for ; Tue, 24 Aug 2004 17:37:49 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 67414 messnum 2909754 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 25 Aug 2004 00:37:48 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail07.svc.cra.dublin.eircom.net (qp 67414) with SMTP; 25 Aug 2004 00:37:48 -0000 Message-ID: <412BDF56.3090805@dehora.net> Date: Wed, 25 Aug 2004 01:37:42 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Peter Saint-Andre CC: atom-syntax@imc.org Subject: Re: Syndication of updates and deletions of content References: <200408231547.BOE99812@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Peter Saint-Andre wrote: > It may be of interest to those looking for notifications related to the > creation, modification, and deletion of Atom entries. This is great :) At work we're building a system that ships rdf/xml encoded system/document related 'events' around using Atom for the package and XMPP as a protocol (it's an application layer syslog). I haven't gotten around to really sitting down and looking at how JEP60 would fit with what we're doing yet... cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 24 21:32:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01441 for ; Tue, 24 Aug 2004 21:32:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P1I2o2091629; Tue, 24 Aug 2004 18:18:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P1I23C091628; Tue, 24 Aug 2004 18:18:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P1I1kk091620 for ; Tue, 24 Aug 2004 18:18:02 -0700 (PDT) (envelope-from distobj@acm.org) Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1BzmRW-0000U3-00; Tue, 24 Aug 2004 21:19:14 -0400 Date: Tue, 24 Aug 2004 21:19:14 -0400 To: Dare Obasanjo Cc: Atom WG Subject: Re: PaceWSDL Message-ID: <20040825011914.GT30868@markbaker.ca> References: <14be96d30408240849283699ca@mail.gmail.com> <20040824165017.73328.qmail@web41203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040824165017.73328.qmail@web41203.mail.yahoo.com> User-Agent: Mutt/1.3.28i From: Mark Baker Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 24, 2004 at 09:50:17AM -0700, Dare Obasanjo wrote: > Quite frankly, > lots of people are going to create WSDLs for the Atom > API (lots already have) and in the interest of interop > I'd rather see them using the same WSDL that different > ones which will all be slightly incompatible. Can you explain how interop is improved by a standard WSDL for Atom? As I see it, as long as the WSDL is used to generate code which implements the Atom protocol accurately, then interop is achieved. This need not require that the same or even compatible WSDL is used, AFAICT. But perhaps there's a use case for it which I'm missing. Or perhaps you have a different definition of "interop"? I can't tell. BTW, I would be very interested in any information you had about tools which support, or plan to support, generating HTTP stubs and skeletons when provided the kind of HTTP-centric WSDL seen in PaceWSDL. I'm skeptical about such an approach being very useful, especially considering how little information is actually in those WSDL documents (when compared with all the information conveyed by HTTP), but I'd be happy to be shown to be wrong. Mark. From owner-atom-syntax@mail.imc.org Tue Aug 24 23:14:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07891 for ; Tue, 24 Aug 2004 23:14:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P34k5b003641; Tue, 24 Aug 2004 20:04:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P34k57003640; Tue, 24 Aug 2004 20:04:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P34jk4003633 for ; Tue, 24 Aug 2004 20:04:45 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <14be96d3040824075565ef4da1@mail.gmail.com> Date: Tue, 24 Aug 2004 20:04:51 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: PaceEquivalents Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:04 AM -0700 8/24/04, Paul Hoffman / IMC wrote: >It is a very bad idea for a stable standard (which is what we intend >for Atom) the equivalents to a document that is not finished (the >FOAF work). Whoops, I muffed a word or two there. That should have read: It is a very bad idea for a stable standard (which is what we intend for Atom) to make equivalents to a document that is not finished (the FOAF work). --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 25 04:22:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23351 for ; Wed, 25 Aug 2004 04:22:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P89h1k038282; Wed, 25 Aug 2004 01:09:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P89hOG038281; Wed, 25 Aug 2004 01:09:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P89gY0038274 for ; Wed, 25 Aug 2004 01:09:43 -0700 (PDT) (envelope-from hildjj@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so216762rnk for ; Wed, 25 Aug 2004 01:09:43 -0700 (PDT) Received: by 10.38.83.11 with SMTP id g11mr875108rnb; Wed, 25 Aug 2004 01:09:43 -0700 (PDT) Received: by 10.38.15.47 with HTTP; Wed, 25 Aug 2004 01:09:43 -0700 (PDT) Message-ID: <82777bea04082501091a292784@mail.gmail.com> Date: Wed, 25 Aug 2004 02:09:43 -0600 From: Joe Hildebrand Reply-To: Joe Hildebrand To: Sam Ruby Subject: Re: Transporting Atom Notifications over the XMPP (was: updates and deletes) Cc: Peter Saint-Andre , atom-syntax@imc.org In-Reply-To: <412BC0C3.20407@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408231547.BOE99812@ms8.netsolmail.com> <412BC0C3.20407@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Without addressing the formatting issues associated with atom:id's, yes, I think it would be useful to use the atom:id as the pubsub item ID. Item ID's have the nice property that if I publish another item with the same ID, the old item gets replaced. Plans for JEP-60 are probably to get some more implementation experience, and move it to Final status. It's currently in Draft status. http://www.jabber.org/jeps/jep-0001.html describes the JSF process. A quote:
In order for a JEP to advance from Proposed to Draft, it must be generally stable, must have resolved known holes in Jabber or deficiencies with existing protocols, must be well-understood by interested and knowledgeable members of the Jabber community, and must be formally defined by an XML schema. Elevation to Draft status is a major advancement for the JEP, indicating a strong belief on the part of the Jabber Council and Jabber community that the specification will be of lasting value. Since a Draft standard must be well-understood and must be known to be reasonably stable, it is relatively safe to use it as the basis for implementations and production deployments. However, note that because a Draft standard may still require additional field experience and may be subject to change based on such experience, mission-critical or large-scale implementations of the Draft standard may not be advisable.
This is a pretty good description of the current state of JEP-60. On Tue, 24 Aug 2004 18:27:15 -0400, Sam Ruby wrote: > > Peter Saint-Andre wrote: > > > > Joe Hildebrand and I have written an individual submission that > > describes methods for sending and receiving Atom notifications via the > > Extensible Messaging and Presence Protocol (XMPP): > > > > http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-00.tx > > t > > > > TinyURL: http://tinyurl.com/4qlbq > > > > It may be of interest to those looking for notifications related to the > > creation, modification, and deletion of Atom entries. > > Do you have any thoughts on how pubsub:id (a.k.a. ItemIDs) should (or > should not) relate to atom:id elements in atom:entry elements contained > within such notifications? > > What are the plans for JEP-0060? > > http://www.jabber.org/jeps/jep-0060.html > > - Sam Ruby > > -- Joe Hildebrand From owner-atom-syntax@mail.imc.org Wed Aug 25 05:33:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27521 for ; Wed, 25 Aug 2004 05:33:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P9GA1O057238; Wed, 25 Aug 2004 02:16:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P9GAga057237; Wed, 25 Aug 2004 02:16:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P9GA6X057221 for ; Wed, 25 Aug 2004 02:16:10 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so169198rnb for ; Wed, 25 Aug 2004 02:16:07 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2059350rnh; Wed, 25 Aug 2004 02:16:07 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 02:16:07 -0700 (PDT) Message-ID: <1f2ed5cd04082502163c655ba6@mail.gmail.com> Date: Wed, 25 Aug 2004 11:16:07 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? Cc: Atom WG In-Reply-To: <20040825001122.21484.qmail@web41215.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825001122.21484.qmail@web41215.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [cc list trimmed] On Tue, 24 Aug 2004 17:11:22 -0700 (PDT), Dare Obasanjo wrote: > --- Danny Ayers wrote: > > > > > > > > 1.) The various link elements proposed in Atom > > have > > > arbitrary semantics. > > > > Not entirely, there are quite a number of > > constraints. They express a > > binary relationship between two unambiguously > > defined entities. The > > relationship is directional and defined by the value > > of the rel > > attribute. This, on top of the disambiguation of > > namespace > > qualification offers a mechanism which is versatile > > without being > > vague. > > To consumers of Atom feeds they have arbitrary > semantics. It seems you are confusing uniform syntax > with uniform semantics. According to the current draft > specs a link could mean (1) users can click here to > see human readable content related to the entry (2) > the URI to send HTTP requests using a variety of > methods [DELETE, POST, PUT, GET] to interact with the > entry (3) a link to an Atom feed that contains entries > that are related to this one in some linear sequence. > > These are pretty arbitrary semantics only connected by > the fact they share uniform syntax. Considering all > the various proposals for potential link elements that > have shown up it is even more clear that if such an > "extensibility" mechanism was chosen there would be > little connection between the semantics or aggregator > behavior on consuming these links besides uniform > syntax. The way has been proposed, syntax is uniform and the semantics are uniform and restricted, not arbitrary: can be defined to express a directed relationship yyy between entities xxx and zzz (the subject xxx will most commonly be an entity defined in the Atom spec). yyy and zzz will be URIs (or be resolvable to URIs), unambiguously identifying the relationship and object. The title, aaa can provide a label for the relationship. In terms of implementation, an aggregator could have a set of specific behaviours will be associated with values for yyy (perhaps also dependent on the parent element). Presumably Atom consumers will already have such a mapping for the core values of 'rel'. In other words a bunch of methods selectable by yyy which take a URI (zzz) as their argument. > > I don't myself think the link mechanism is perfect, > > not even adequate. > > But at the moment the other alternatives are either > > limiting the > > applicability of Atom (by restricting things to core > > terms) or > > allowing anything anywhere (with namespaces) and > > introducing a barrier > > to interop. > > You're kidding right? How is seeing an entry with > > type="text/javascript" rel="make-it-crunk" /> > > any different from seeing the same one with > > http:cc="http://www.example.com/cc"> > > ftp://www.example.com/pool.js > > > What exactly makes the former a recipe for > interoperability and the latter a barrier? The former can offer uniform syntax and well-defined semantics, based on the simple definition above. I don't know of any systematic way of interpreting the latter example. The syntax and semantic restrictions mean that it should be possible to avoid/minimise collisions between extensions relatively easily. With namespaces alone that is a hard problem. In terms of implementation, the same class/method selector code could be used for all elements. Parsing can take place at the level of the rest of the Atom syntax. On the other hand, every new piece of syntax like crunchitize-me-capn will need 1. new code for parsing (on top of Atom) and 2. new code for routing of the discovered arguments to the appropriate handlers. You would probably need some conflict resolution code too, for cases where extension material from different namespaces was linked to incompatible sets of behaviour. Additionally every producer would need a corresponding block of syntax construction code for each crunchitize-me-capn extension. The construction code simply needs code to place it in the appropriate part of the tree (which is probably already available from core handling) and two or three setter methods: href, rel, title. Do you > seriously think that the fact that one could render > the latter in the browser as a clickable link somehow > makes it more useful than the latter? If so do you > think the same about rel="service.post" and rel="service.edit"? I'm not sure what you mean. The example could easily be rendered as a clickable link if that was an appropriate rendering, though given the values for 'rel' that have been suggested I would think that would be the exception rather than the rule. Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Aug 25 08:20:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09864 for ; Wed, 25 Aug 2004 08:20:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PC47Ze099895; Wed, 25 Aug 2004 05:04:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PC47wu099894; Wed, 25 Aug 2004 05:04:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf09.cluster1.charter.net (mxsf09.cluster1.charter.net [209.225.28.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PC46qm099857 for ; Wed, 25 Aug 2004 05:04:07 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from mxip16.cluster1.charter.net (mxip16a.cluster1.charter.net [209.225.28.146]) by mxsf09.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i7PC40He028357 for ; Wed, 25 Aug 2004 08:04:00 -0400 Received: from cpe-68-112-239-32.ma.charter.com (HELO mercury) (68.112.239.32) by mxip16.cluster1.charter.net with ESMTP; 25 Aug 2004 08:04:00 -0400 X-Ironport-AV: i="3.84,106,1091419200"; d="scan'208"; a="244476000:sNHT19156724" Received: from ndw by mercury with local (Exim 3.36 #1 (Debian)) id 1BzwUs-000812-00 for ; Wed, 25 Aug 2004 08:03:22 -0400 To: Atom Syntax Subject: Feeds MUST have alternate links? From: Norman Walsh X-URL: http://nwalsh.com/ Date: Wed, 25 Aug 2004 08:03:20 -0400 Message-ID: <87smabifw7.fsf@nwalsh.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain The 01 draft says: 4.2.2 "atom:link" Element The "atom:link" element is a Link construct that conveys a URI associated with the feed. The nature of the relationship as well as the link itself is determined by the element's content. atom:head elements MUST contain at least one atom:link element with a rel attribute value of "alternate". Why must I produce an alternate representation of the feed? I have a practical reason for asking. Someone asked me to produce a feed for all the photographs on norman.walsh.name. I can do that, but I'm not going to produce an HTML page that is an alternate representation of that feed. I suppose I could, but I'd rather not and I don't see why I should. Be seeing you, norm -- Norman Walsh | When dealing with the insane, the best http://nwalsh.com/ | method is to pretend to be | sane.--Hermann Hesse --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBLIAKOyltUcwYWjsRAjikAJ4zd11i3ivXmtsFg/NnQOd0mQCrqQCfc7X3 W9NcvfUNaOATmyZ6m1uujfo= =VzPc -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Aug 25 08:23:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10087 for ; Wed, 25 Aug 2004 08:23:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PCFZFV002986; Wed, 25 Aug 2004 05:15:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PCFZOQ002985; Wed, 25 Aug 2004 05:15:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PCFZRk002973 for ; Wed, 25 Aug 2004 05:15:35 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so157862rnb for ; Wed, 25 Aug 2004 05:15:36 -0700 (PDT) Received: by 10.38.1.62 with SMTP id 62mr2103090rna; Wed, 25 Aug 2004 05:15:36 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 05:15:36 -0700 (PDT) Message-ID: <1f2ed5cd04082505156a8d236b@mail.gmail.com> Date: Wed, 25 Aug 2004 14:15:36 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Paul Hoffman / IMC Subject: Re: PaceEquivalents Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <14be96d3040824075565ef4da1@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > At 10:04 AM -0700 8/24/04, Paul Hoffman / IMC wrote: > >It is a very bad idea for a stable standard (which is what we intend > >for Atom) [to make] equivalents to a document that is not finished (the > >FOAF work). True, although perhaps you have that the wrong way around - the core terms in FOAF haven't changed in 3+ years, DC has been around forever and Atom isn't finished. But in any case, this is why the word "suggested" is used repeatedly in the Pace. People *will* want to use Atom terms alongside other vocabularies and the intention of the Pace was to "help in the definition of such mappings", not to define the equivalences. Just informative. If, as Mark says, the definitions of terms such as issued, created and modified are going to be significantly different from their DC namesakes then perhaps what is needed is a PaceNotEquivalents to prevent people from assuming that things with same (local) names used in the syndication space have the same meaning. Oh, the joys of reinvention... Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Aug 25 09:22:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13207 for ; Wed, 25 Aug 2004 09:22:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDDxe1014784; Wed, 25 Aug 2004 06:13:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PDDxWL014783; Wed, 25 Aug 2004 06:13:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDDwHi014762 for ; Wed, 25 Aug 2004 06:13:58 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so114147rnl for ; Wed, 25 Aug 2004 06:13:52 -0700 (PDT) Received: by 10.38.72.60 with SMTP id u60mr768384rna; Wed, 25 Aug 2004 06:13:51 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Wed, 25 Aug 2004 06:13:51 -0700 (PDT) Message-ID: <14be96d304082506137a652eb3@mail.gmail.com> Date: Wed, 25 Aug 2004 09:13:51 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Norman Walsh Subject: Re: Feeds MUST have alternate links? Cc: Atom Syntax In-Reply-To: <87smabifw7.fsf@nwalsh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <87smabifw7.fsf@nwalsh.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 08:03:20 -0400, Norman Walsh wrote: > The 01 draft says: > > 4.2.2 "atom:link" Element > > The "atom:link" element is a Link construct that conveys a URI > associated with the feed. The nature of the relationship as well as > the link itself is determined by the element's content. > > atom:head elements MUST contain at least one atom:link element with a > rel attribute value of "alternate". > > Why must I produce an alternate representation of the feed? > > I have a practical reason for asking. Someone asked me to produce a > feed for all the photographs on norman.walsh.name. I can do that, but > I'm not going to produce an HTML page that is an alternate > representation of that feed. I suppose I could, but I'd rather not and > I don't see why I should. I think http://norman.walsh.name/topics#Photography would suffice as an alternate link for that feed. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed Aug 25 09:23:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13255 for ; Wed, 25 Aug 2004 09:23:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDBRS0013857; Wed, 25 Aug 2004 06:11:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PDBRdm013856; Wed, 25 Aug 2004 06:11:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDBQtn013824 for ; Wed, 25 Aug 2004 06:11:26 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so120401rnk for ; Wed, 25 Aug 2004 06:11:23 -0700 (PDT) Received: by 10.38.72.72 with SMTP id u72mr1937604rna; Wed, 25 Aug 2004 06:11:23 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Wed, 25 Aug 2004 06:11:23 -0700 (PDT) Message-ID: <14be96d3040825061141c9ec63@mail.gmail.com> Date: Wed, 25 Aug 2004 09:11:23 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Danny Ayers Subject: Re: PaceEquivalents Cc: Paul Hoffman / IMC , Atom WG In-Reply-To: <1f2ed5cd04082505156a8d236b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <14be96d3040824075565ef4da1@mail.gmail.com> <1f2ed5cd04082505156a8d236b@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 14:15:36 +0200, Danny Ayers wrote: > > At 10:04 AM -0700 8/24/04, Paul Hoffman / IMC wrote: > > >It is a very bad idea for a stable standard (which is what we intend > > >for Atom) [to make] equivalents to a document that is not finished (the > > >FOAF work). > > True, although perhaps you have that the wrong way around - the core > terms in FOAF haven't changed in 3+ years Quoting from : FOAF Vocabulary Specification Namespace Document 1 May 2004 Latest version: http://xmlns.com/foaf/0.1/ Last update: $Date: 2004/08/18 00:31:33 $ Revision: $Revision: 1.64 $ ... Status of This Document NOTE:This specification is an evolving document. The bulk of this document is now generated by combining the RDFS/OWL machine-readable FOAF ontology with a set of per-term documents. The remaining sections require serious attention; we are well aware that better examples and tighter intro text are needed. > If, as Mark says, the definitions of terms such as issued, created and > modified are going to be significantly different from their DC > namesakes then perhaps what is needed is a PaceNotEquivalents to > prevent people from assuming that things with same (local) names used > in the syndication space have the same meaning. Oh, the joys of > reinvention... IIRC, most of the contention centered around the vagueness of the DC terms. Does "issued" mean "first-issued" or "most-recently-issued"? Can it mean "re-issued"? Does "modified" mean any modification, or just "significant" modification? Oh, the joys of selective memory... -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed Aug 25 09:52:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15327 for ; Wed, 25 Aug 2004 09:52:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDf5WB019718; Wed, 25 Aug 2004 06:41:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PDf5Jt019717; Wed, 25 Aug 2004 06:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDf4cM019703 for ; Wed, 25 Aug 2004 06:41:05 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7PDf2dk019944; Wed, 25 Aug 2004 09:41:02 -0400 Message-ID: <412C96EC.8050400@intertwingly.net> Date: Wed, 25 Aug 2004 09:41:00 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: Peter Saint-Andre , atom-syntax@imc.org Subject: Re: Transporting Atom Notifications over the XMLPP References: <200408231547.BOE99812@ms8.netsolmail.com> <412BC0C3.20407@intertwingly.net> <82777bea04082501091a292784@mail.gmail.com> In-Reply-To: <82777bea04082501091a292784@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > Without addressing the formatting issues associated with atom:id's, > yes, I think it would be useful to use the atom:id as the pubsub item > ID. Item ID's have the nice property that if I publish another item > with the same ID, the old item gets replaced. What's the process for getting draft-saintandre-atompub-notify updated? I see three basic approaches, which I will list in my order of preference: 1) decide that the pubsub item ID MUST be the same as the atom:id when transporting Atom notifications over the XMLPP. 2) decide that atom:id and pubsub item ID are orthogonal concepts and discourage (either implicitly via examples, or explicitly via prose) these concepts from being confused. 3) decide that atom:id SHOULD be used as the pubsub item ID, but that consumers MUST NOT presume that they are the same. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 25 10:06:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16753 for ; Wed, 25 Aug 2004 10:06:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PE04dQ024797; Wed, 25 Aug 2004 07:00:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PE049q024796; Wed, 25 Aug 2004 07:00:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PE04vs024788 for ; Wed, 25 Aug 2004 07:00:04 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7PE0653003802 for ; Wed, 25 Aug 2004 08:00:06 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I30004TD9K5CC@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 25 Aug 2004 08:00:06 -0600 (MDT) Received: from [192.168.1.15] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I3000CFV9K4E1@mail.sun.net> for atom-syntax@imc.org; Wed, 25 Aug 2004 08:00:05 -0600 (MDT) Date: Wed, 25 Aug 2004 06:59:59 -0700 From: Tim Bray Subject: Re: Feeds MUST have alternate links? In-reply-to: <87smabifw7.fsf@nwalsh.com> To: Norman Walsh Cc: Atom Syntax Message-id: <0D5F1A38-F69F-11D8-84A8-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <87smabifw7.fsf@nwalsh.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 25, 2004, at 5:03 AM, Norman Walsh wrote: > The 01 draft says: > > 4.2.2 "atom:link" Element > > The "atom:link" element is a Link construct that conveys a URI > associated with the feed. The nature of the relationship as well > as > the link itself is determined by the element's content. > > atom:head elements MUST contain at least one atom:link element > with a > rel attribute value of "alternate". > > Why must I produce an alternate representation of the feed? Practically speaking, in NetNewsWire, I can click on any of the feeds in my subscription list, and it usually sends my browser somewhere sensible, normally the front page of the blog or news service or whatever that I'm subscribed to. Clearly in some cases, figuring what best to put there can involve a judgement call. -Tim From owner-atom-syntax@mail.imc.org Wed Aug 25 10:31:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19398 for ; Wed, 25 Aug 2004 10:31:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PENvVJ029642; Wed, 25 Aug 2004 07:23:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PENvpR029641; Wed, 25 Aug 2004 07:23:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PENunh029629 for ; Wed, 25 Aug 2004 07:23:56 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1Bzygs-0005Js-Tg for atom-syntax@imc.org; Wed, 25 Aug 2004 14:23:55 +0000 Message-ID: <412CA0F6.2070404@franklinmint.fm> Date: Wed, 25 Aug 2004 10:23:50 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceServiceError updated Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Previous discussions (pre-IETF) have shown that POST is inappropriate[0] for PaceServiceError, and I'm the only one that thinks GET is ok. PaceErrVerb proposes a new verb, but requires that the request be sent to the requested URI. I've updated PaceServiceError to use a new method: GRUMBLE. We can change the name ;), I just didn't want to get it confused with PaceErrVerb in discussion. The URIs are all absolute now, per feedback from Bill de HÓra. Once again, I'd like to note that participation is completely optional for client and server. For example, a server may choose to include "Atom-Error" headers only for authenticated clients. I think it was Mark Baker who pointed out that new HTTP methods are "mustUnderstand". That's exactly what this feature needs. A bogus GRUMBLE request is no more dangerous than a bogus IMG @src. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg05568.html From owner-atom-syntax@mail.imc.org Wed Aug 25 10:36:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19813 for ; Wed, 25 Aug 2004 10:36:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PESkBH030567; Wed, 25 Aug 2004 07:28:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PESkOJ030566; Wed, 25 Aug 2004 07:28:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PESjdp030559 for ; Wed, 25 Aug 2004 07:28:45 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7PESl4d005027 for ; Wed, 25 Aug 2004 07:28:47 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I3000801AU5F1@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Wed, 25 Aug 2004 10:28:47 -0400 (EDT) Received: from mercury (vpn-129-150-34-79.Central.Sun.COM [129.150.34.79]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I3000D4UAVY9N@bur-mail1.east.sun.com> for atom-syntax@imc.org; Wed, 25 Aug 2004 10:28:47 -0400 (EDT) Received: from ndw by mercury with local (Exim 3.36 #1 (Debian)) id 1Bzyl0-0002it-00 for ; Wed, 25 Aug 2004 10:28:10 -0400 X-URL: http://nwalsh.com/ Date: Wed, 25 Aug 2004 10:28:04 -0400 From: Norman Walsh Subject: Re: Feeds MUST have alternate links? In-reply-to: <14be96d304082506137a652eb3@mail.gmail.com> To: Atom Syntax Message-id: <876577gumj.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) References: <87smabifw7.fsf@nwalsh.com> <14be96d304082506137a652eb3@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain / Mark Pilgrim was heard to say: | I think http://norman.walsh.name/topics#Photography would suffice as | an alternate link for that feed. Yeah. I suppose. I guess I was thinking too literally. Be seeing you, norm -- Norman Walsh | The stone fell on the pitcher? Woe to http://nwalsh.com/ | the pitcher. The pitcher fell on the | stone? Woe to the pitcher.--Rabbinic | Saying --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBLKH0OyltUcwYWjsRAkwSAJ9aaBQ/a/tHTYy76w0oe5VmFegt8wCfZb7v H6esDumN+PrF7kRupZAJBII= =VBfl -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Aug 25 10:55:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21012 for ; Wed, 25 Aug 2004 10:55:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PEhn2R035441; Wed, 25 Aug 2004 07:43:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PEhn88035440; Wed, 25 Aug 2004 07:43:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PEhnrZ035419 for ; Wed, 25 Aug 2004 07:43:49 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825144347.61477.qmail@web41210.mail.yahoo.com> Received: from [24.18.130.238] by web41210.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 07:43:47 PDT Date: Wed, 25 Aug 2004 07:43:47 -0700 (PDT) From: Dare Obasanjo Subject: Re: Can atom be Del.icio.us? Or, can Del.icio.us be atomic? To: Danny Ayers Cc: Atom WG In-Reply-To: <1f2ed5cd04082502163c655ba6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Danny Ayers wrote: > > The way has been proposed, syntax is uniform > and the semantics > are uniform and restricted, not arbitrary: > > > > > > can be defined to express a directed relationship > yyy between entities > xxx and zzz (the subject xxx will most commonly be > an entity defined > in the Atom spec). yyy and zzz will be URIs (or be > resolvable to > URIs), unambiguously identifying the relationship > and object. The > title, aaa can provide a label for the relationship. I give up. Telling me that I get a {rel, uri} pair and that gives me some semantics is a joke. If I didn't know you were one of the RDF-will-save-the-world clique I'd have assumed you were trolling since no one can be this obtuse without being deliberate. > In terms of implementation, an aggregator could have > a set of specific > behaviours will be associated with values for yyy > (perhaps also > dependent on the parent element). Presumably Atom > consumers will > already have such a mapping for the core values of > 'rel'. In other > words a bunch of methods selectable by yyy which > take a URI (zzz) as > their argument. Can you show me this code? Even better why don't you send me the patch for RSS Bandit that can handle any arbitrary {uri, rel} pair and correctly interprets their semantics without doing something stupid like displaying the rel="service.post" URI as a clickable link. I guess this is where RDF and OWL show up to save the day. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Wed Aug 25 11:11:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22238 for ; Wed, 25 Aug 2004 11:11:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PF4dtF040509; Wed, 25 Aug 2004 08:04:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PF4dHa040508; Wed, 25 Aug 2004 08:04:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from giles.cursive.net (dsl081-100-205.den1.dsl.speakeasy.net [64.81.100.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PF4cLB040485 for ; Wed, 25 Aug 2004 08:04:38 -0700 (PDT) (envelope-from hildjj@cursive.net) Received: from [10.2.1.62] ([207.182.164.14]) by giles.cursive.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 Aug 2004 09:04:33 -0600 In-Reply-To: <412C96EC.8050400@intertwingly.net> References: <200408231547.BOE99812@ms8.netsolmail.com> <412BC0C3.20407@intertwingly.net> <82777bea04082501091a292784@mail.gmail.com> <412C96EC.8050400@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5A76B808-F6A0-11D8-8422-000A959A17A6@cursive.net> Content-Transfer-Encoding: 7bit Cc: Peter Saint-Andre , atom-syntax@imc.org, Joe Hildebrand From: Joe Hildebrand Subject: Re: Transporting Atom Notifications over the XMLPP Date: Wed, 25 Aug 2004 08:09:18 -0600 To: Sam Ruby X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 25 Aug 2004 15:04:36.0063 (UTC) FILETIME=[D5E6B6F0:01C48AB4] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is as good a forum as any to discuss it, and we're certainly willing to make mods to suit the community on both sides. On your options: 1) this would work. I don't see any downside, but it's pretty hard to enforce. 2) I don't think this is right. No need for yet another GUID-y thing in the world. 3) This is probably right. For example, I wouldn't want to have people look at the pub/sub ID and not the atom:id in order to do uniqueness checks. That would be a layering problem. -- Joe Hildebrand Denver, CO, USA On Aug 25, 2004, at 7:41 AM, Sam Ruby wrote: > > Joe Hildebrand wrote: > >> Without addressing the formatting issues associated with atom:id's, >> yes, I think it would be useful to use the atom:id as the pubsub item >> ID. Item ID's have the nice property that if I publish another item >> with the same ID, the old item gets replaced. > > What's the process for getting draft-saintandre-atompub-notify updated? > > I see three basic approaches, which I will list in my order of > preference: > > 1) decide that the pubsub item ID MUST be the same as the atom:id when > transporting Atom notifications over the XMLPP. > > 2) decide that atom:id and pubsub item ID are orthogonal concepts and > discourage (either implicitly via examples, or explicitly via prose) > these concepts from being confused. > > 3) decide that atom:id SHOULD be used as the pubsub item ID, but that > consumers MUST NOT presume that they are the same. > > - Sam Ruby > From owner-atom-syntax@mail.imc.org Wed Aug 25 11:24:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23373 for ; Wed, 25 Aug 2004 11:24:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFFB7d042789; Wed, 25 Aug 2004 08:15:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PFFBpm042788; Wed, 25 Aug 2004 08:15:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PFF96S042755 for ; Wed, 25 Aug 2004 08:15:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 29734 messnum 2841356 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 25 Aug 2004 15:15:07 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail07.svc.cra.dublin.eircom.net (qp 29734) with SMTP; 25 Aug 2004 15:15:07 -0000 Message-ID: <412CACF6.7020000@dehora.net> Date: Wed, 25 Aug 2004 16:15:02 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom WG CC: Tim Bray , Paul Hoffman / IMC Subject: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> In-Reply-To: <20040825144347.61477.qmail@web41210.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, I'd like to draw the chair's attention to these sprited rejoinders. since they're not helping us make progress wrt the Del.icio.us issue. Utterances from the chairs about staying focused and maintaining a basic level of civility would be much appreciated. On a personal note. If I see another ill-mannered, ill-informed, ill-engaged, ill-defined spat about "extensibility" or "versioning" viz RDF/XML/URIs, I'll surely scream, or start killfiling. As someone who uses both RDF and XML to get things done, I'm getting really annoyed about this. cheers Bill Dare Obasanjo wrote: > > --- Danny Ayers wrote: > > >> >>The way has been proposed, syntax is uniform >>and the semantics >>are uniform and restricted, not arbitrary: >> >> >> >> >> >>can be defined to express a directed relationship >>yyy between entities >>xxx and zzz (the subject xxx will most commonly be >>an entity defined >>in the Atom spec). yyy and zzz will be URIs (or be >>resolvable to >>URIs), unambiguously identifying the relationship >>and object. The >>title, aaa can provide a label for the relationship. > > > I give up. Telling me that I get a {rel, uri} pair and > that gives me some semantics is a joke. If I didn't > know you were one of the RDF-will-save-the-world > clique I'd have assumed you were trolling since no one > can be this obtuse without being deliberate. > > >>In terms of implementation, an aggregator could have >>a set of specific >>behaviours will be associated with values for yyy >>(perhaps also >>dependent on the parent element). Presumably Atom >>consumers will >>already have such a mapping for the core values of >>'rel'. In other >>words a bunch of methods selectable by yyy which >>take a URI (zzz) as >>their argument. > > > Can you show me this code? Even better why don't you > send me the patch for RSS Bandit that can handle any > arbitrary {uri, rel} pair and correctly interprets > their semantics without doing something stupid like > displaying the rel="service.post" URI as a clickable > link. > > I guess this is where RDF and OWL show up to save the > day. > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 > No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > > > From owner-atom-syntax@mail.imc.org Wed Aug 25 11:38:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24547 for ; Wed, 25 Aug 2004 11:38:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFTNZj045767; Wed, 25 Aug 2004 08:29:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PFTNv1045766; Wed, 25 Aug 2004 08:29:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFTM7I045744 for ; Wed, 25 Aug 2004 08:29:22 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@ms8.netsolmail.com [216.168.230.180] (may be forged)) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7PFTH6g015377; Wed, 25 Aug 2004 11:29:19 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOM29634 (AUTH bob@wyman.us); Wed, 25 Aug 2004 11:29:16 -0400 (EDT) Message-Id: <200408251529.BOM29634@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" , "'Joe Hildebrand'" Cc: "'Peter Saint-Andre'" , Subject: RE: Transporting Atom Notifications over the XMLPP Date: Wed, 25 Aug 2004 11:27:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <412C96EC.8050400@intertwingly.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSKq9DHJulP7RoqSi+iPQz9l2S7MAACOVPg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: >What's the process for getting draft-saintandre-atompub-notify updated? Before too much energy goes into updating the draft, there should be a great deal more experience gained with working with Atom over XMPP. Frankly, I think this is an ID issued "before it's time..." As far as I know, PubSub.com is the only publicly announced implementer of an Atom over XMPP system and we have only a handful of clients that read data from us (they will be announced later this week.) Given this, there is still a great deal of learning that needs to happen before Atom over XMPP can be properly defined. We should also get farther along in the definition of Atom itself before trying to lock too much in stone. For instance, as has been noted in other messages, there is concern that people will be implementing multiple versions of Atom or implementing features of the "new" Atom before they are well understood. This is one reason why the PubSub.com implementation of Atom over XMPP relies exclusively on Atom 0.3 rather than features taken from the current drafts. However, in response to email exchanges between the authors of the ID and me, the ID incorporates features of the current draft: Entry is a top-level object while Atom 0.3 requires that each entry be wrapped by a feed element. While "new" Atom approach is definitely better, it is premature to encourage people to implement such a thing -- and they will implement it if there is an ID describing it. > 2) decide that atom:id and pubsub item ID are orthogonal concepts > and discourage (either implicitly via examples, or explicitly via > prose) these concepts from being confused. +1. atom:id and pubsub item ID are orthogonal for reasons described in earlier email. i.e. Atom provides no mechanism to *ensure* that atom:id's are globally unique even though it is "required" that they be globally unique. Thus, in order to prevent malicious attacks, aggregate feeds would be forced to create new id's for all entries. This is not good. bob wyman From owner-atom-syntax@mail.imc.org Wed Aug 25 11:54:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25909 for ; Wed, 25 Aug 2004 11:54:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFhHG7049130; Wed, 25 Aug 2004 08:43:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PFhHsU049129; Wed, 25 Aug 2004 08:43:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFhGPr049097 for ; Wed, 25 Aug 2004 08:43:17 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so115578rnl for ; Wed, 25 Aug 2004 08:43:16 -0700 (PDT) Received: by 10.38.206.33 with SMTP id d33mr177386rng; Wed, 25 Aug 2004 08:43:16 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 08:43:16 -0700 (PDT) Message-ID: <1f2ed5cd040825084376782283@mail.gmail.com> Date: Wed, 25 Aug 2004 17:43:16 +0200 From: Danny Ayers Reply-To: Danny Ayers To: "Bill de hÓra" Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Cc: Atom WG , Tim Bray , Paul Hoffman / IMC In-Reply-To: <412CACF6.7020000@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7PFhHPr049118 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 25 Aug 2004 16:15:02 +0100, Bill de hÓra wrote: > > Hi, > > I'd like to draw the chair's attention to these sprited rejoinders. No need Bill, I've had enough. The extensibility thread (dating back since before Atom got its name) might as well have been killfiled already. Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Aug 25 11:59:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22236 for ; Wed, 25 Aug 2004 11:11:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PF4sZA040598; Wed, 25 Aug 2004 08:04:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PF4soM040597; Wed, 25 Aug 2004 08:04:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PF4rIK040542 for ; Wed, 25 Aug 2004 08:04:53 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id 002D0171D7C; Wed, 25 Aug 2004 11:04:45 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Joe Hildebrand'" , "'Sam Ruby'" Cc: "'Peter Saint-Andre'" , Subject: RE: Transporting Atom Notifications over the XMPP (was: updates and deletes) Date: Wed, 25 Aug 2004 11:02:45 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <82777bea04082501091a292784@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSKfXYX99i/wu0ERCyfOYspj6n6wwAMttew Message-Id: <20040825150446.002D0171D7C@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > Without addressing the formatting issues associated with atom:id's, > yes, I think it would be useful to use the atom:id as the pubsub > item ID. Item ID's have the nice property that if I publish another > item with the same ID, the old item gets replaced. Using the atom:id as the XMPP/PubSub item id is *not* a good idea. 1. As has been noted elsewhere, while atom:id's are "required" to be globally unique, there is no mechanism which ensures that they are, in fact, globally unique. Thus, there is a significant risk that in aggregate feeds, items from different source feeds will improperly replace each other simply because they have the same atom:id. To prevent this, an aggregate feed producer would have to create new atom:id's for each aggregated entry and thus break the rule that an atom entry is to have the same atom:id in all feeds in which it appears. 2. This is a mixing of architectural layers. Data from the message or application layer should not be used in the transport layer. In this case, XMPP and the pubsub elements of JEP-0060 should be considered transport layer and should be application independent. If the layering is broken, it becomes difficult to implement transport layer functions without interfering with application layer semantics. Note: As far as I know, the first and only publicly available implementation of Atom over XMPP is the one that we have built at PubSub.com and, although we are not even acknowledged in the Internet Draft, most of it (and substantial portions of JEP-0060) is based on our publicly discussed work and email/phone discussions with the authors of the ID... For those who wish to experiment with Atom over XMPP, I encourage you to read more about our service at: http://www.pubsub.com/developers.php . On that page, you'll find pointers to our "tutorial" on how to do Atom over XMPP as well as pointers to an open source client that we've placed on sourceforge. bob wyman From owner-atom-syntax@mail.imc.org Wed Aug 25 12:02:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26548 for ; Wed, 25 Aug 2004 12:02:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFoQC4050533; Wed, 25 Aug 2004 08:50:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PFoQ1R050532; Wed, 25 Aug 2004 08:50:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFoP1a050522 for ; Wed, 25 Aug 2004 08:50:26 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <412CACF6.7020000@dehora.net> References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> Date: Wed, 25 Aug 2004 08:50:25 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 4:15 PM +0100 8/25/04, Bill de hÓra wrote: >Utterances from the chairs about staying focused and maintaining a >basic level of civility would be much appreciated. So uttered. It is always better to use technical arguments than personal attacks. If you can't think of anything to say that has technical merit, silence should be considered a strong option. >On a personal note. If I see another ill-mannered, ill-informed, >ill-engaged, ill-defined spat about "extensibility" or "versioning" >viz RDF/XML/URIs, I'll surely scream, or start killfiling. As >someone who uses both RDF and XML to get things done, I'm getting >really annoyed about this. It would be a very major shift for this WG to change the Atom format to RDF. If someone wants to make a proposal for that, they should have a list of at least three active WG members as co-proponents before starting the discussion. Further, they should expect a fair amount of criticism for re-hashing old arguments. Absent an active proposal, discussing advantages of RDF or other significant base changes is out of scope. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 25 12:02:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26579 for ; Wed, 25 Aug 2004 12:02:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFtOdW051890; Wed, 25 Aug 2004 08:55:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PFtOVj051889; Wed, 25 Aug 2004 08:55:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41211.mail.yahoo.com (web41211.mail.yahoo.com [66.218.93.44]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PFtOYc051862 for ; Wed, 25 Aug 2004 08:55:24 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825155522.44418.qmail@web41211.mail.yahoo.com> Received: from [24.18.130.238] by web41211.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 08:55:22 PDT Date: Wed, 25 Aug 2004 08:55:22 -0700 (PDT) From: Dare Obasanjo Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] To: "Bill_de_hÓra" , Atom WG Cc: Tim Bray , Paul Hoffman / IMC In-Reply-To: <412CACF6.7020000@dehora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Bill_de_hÓra wrote: > > Hi, > > I'd like to draw the chair's attention to these > sprited rejoinders. > since they're not helping us make progress wrt the > Del.icio.us > issue. How are they not? If there was extensibility and link types defined then Del.icio.us and Mark Pilgrim can cook up all the link types they want as long as there was some consistent way to know how to treat link types. Heck, a straightforward solution would be just to use XLink or define some profile of XLink to use in Atom. The only problem seems to be that no one wants to step up to the plate and do it. I'm not interested enough in the problem to spend time on it but that seems like a decent solution. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 25 12:31:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28653 for ; Wed, 25 Aug 2004 12:31:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGNcs3057927; Wed, 25 Aug 2004 09:23:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PGNchr057926; Wed, 25 Aug 2004 09:23:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGNbSv057908 for ; Wed, 25 Aug 2004 09:23:37 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7PGNaZa028856; Wed, 25 Aug 2004 12:23:39 -0400 Message-ID: <412CBD05.6020307@intertwingly.net> Date: Wed, 25 Aug 2004 12:23:33 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Atom WG Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] References: <20040825155522.44418.qmail@web41211.mail.yahoo.com> In-Reply-To: <20040825155522.44418.qmail@web41211.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dare Obasanjo wrote: > > --- Bill_de_hÓra wrote: > >>Hi, >> >>I'd like to draw the chair's attention to these >>sprited rejoinders. >>since they're not helping us make progress wrt the >>Del.icio.us >>issue. > > How are they not? If there was extensibility > and link types defined then Del.icio.us and Mark > Pilgrim can cook up all the link types they want as > long as there was some consistent way to know how to > treat link types. Statements like "If I didn't know you were one of the RDF-will-save-the-world clique I'd have assumed you were trolling since no one can be this obtuse without being deliberate."[1] do not further the goals of having a productive technical discussion. Reminder: "Sometimes it is easy to forget that the people on the other end of an email thread aren't former denizens of git.talk.flame who relish technical arguments spiced with flame."[2] > Heck, a straightforward solution would be just to use > XLink or define some profile of XLink to use in Atom. > The only problem seems to be that no one wants to step > up to the plate and do it. I'm not interested enough > in the problem to spend time on it but that seems like > a decent solution. At the moment, the Atom link element is modelled after the HTML link tag[3], which has a number of advantages[4]. - Sam Ruby [1] [2] [3] [4] From owner-atom-syntax@mail.imc.org Wed Aug 25 12:31:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28671 for ; Wed, 25 Aug 2004 12:31:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGO6ks058066; Wed, 25 Aug 2004 09:24:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PGO68p058065; Wed, 25 Aug 2004 09:24:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGO5OX058053 for ; Wed, 25 Aug 2004 09:24:05 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 2575 invoked by uid 17064); 25 Aug 2004 16:24:04 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.136.80]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Aug 2004 16:24:04 -0000 In-Reply-To: References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <2B9035AF-F6B3-11D8-ADE0-000A95D9FA7A@bblfish.net> Cc: Danny Ayers , Paul Hoffman / IMC , =?ISO-8859-1?Q?Bill_de_h=D3ra?= From: Henry Story Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Date: Wed, 25 Aug 2004 18:23:59 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7PGO5OX058056 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 25 Aug 2004, at 17:50, Paul Hoffman / IMC wrote: > > It would be a very major shift for this WG to change the Atom format > to RDF. If someone wants to make a proposal for that, they should have > a list of at least three active WG members as co-proponents before > starting the discussion. Further, they should expect a fair amount of > criticism for re-hashing old arguments. Absent an active proposal, > discussing advantages of RDF or other significant base changes is out > of scope. I don't think that Danny was proposing to shift to RDF. He was in fact putting forward an extremely minimalist proposal for allowing extensibility in Atom, following furthermore a convention to be adopted by the next version of xhtml. Without a proposal of the sort it would seem there is no way that Atom can fulfill one of the elements of the charter [1], namely: -----8<--------------------------------------------- The working group will also take steps to ensure interoperability, by: • unambiguously identifying required elements in formats • clearly nominating conformance levels for different types of software • providing clear extensibility mechanisms and constraints upon them -----8<--------------------------------------------- So given that the above is an avowed goal of this group, it is clear that Dare Obasanjo's comment: > If I didn't > know you were one of the RDF-will-save-the-world > clique I'd have assumed you were trolling since no one > can be this obtuse without being deliberate. is in fact extreemly impolite given the huge effort and calm shown by Danny Ayers in explaining this issue. I myself think that this RDF issue should be re-opened, because I have not yet seen any good arguments against it and it is fully supported by the founder of the web himself, Tim Berner's Lee. If that is not a good enough pedigree for an idea I don't know what is. If Dare Obansanjo has to rewrite a few scripts if we find we have to change things, then I can just say I am very sorry for him. But this is a forum for creating a powerful, top notch, earth chattering protocol, or else everyone here is just wasting everyone else's time. > > --Paul Hoffman, Director > --Internet Mail Consortium [1] http://xml.coverpages.org/IETF-atompubProposed.html From owner-atom-syntax@mail.imc.org Wed Aug 25 12:42:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29692 for ; Wed, 25 Aug 2004 12:42:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGYmPG060195; Wed, 25 Aug 2004 09:34:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PGYmFM060194; Wed, 25 Aug 2004 09:34:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGYl9D060160 for ; Wed, 25 Aug 2004 09:34:48 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so184455rnb for ; Wed, 25 Aug 2004 09:34:45 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2214807rnh; Wed, 25 Aug 2004 09:34:44 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 09:34:44 -0700 (PDT) Message-ID: <1f2ed5cd040825093474710cae@mail.gmail.com> Date: Wed, 25 Aug 2004 18:34:44 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Paul Hoffman / IMC Subject: Re: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 08:50:25 -0700, Paul Hoffman / IMC wrote: > It would be a very major shift for this WG to change the Atom format > to RDF. If someone wants to make a proposal for that, they should > have a list of at least three active WG members as co-proponents > before starting the discussion. Further, they should expect a fair > amount of criticism for re-hashing old arguments. Absent an active > proposal, discussing advantages of RDF or other significant base > changes is out of scope. I fully accept that the Atom format isn't going to be RDF/XML, and that there won't be a normative RDF model for Atom. But if you look back to the start of the del.icio.us thread the issue raised was that Atom couldn't do something that RSS/RDF could. In or out of of scope? For the record, my suggestion for handling this case did not involve RDF. Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Aug 25 13:02:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00842 for ; Wed, 25 Aug 2004 13:02:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGoc7e063506; Wed, 25 Aug 2004 09:50:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PGoc1d063505; Wed, 25 Aug 2004 09:50:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from giles.cursive.net (dsl081-100-205.den1.dsl.speakeasy.net [64.81.100.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGoclR063475 for ; Wed, 25 Aug 2004 09:50:38 -0700 (PDT) (envelope-from hildjj@cursive.net) Received: from [10.2.1.62] ([207.182.164.14]) by giles.cursive.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 Aug 2004 10:50:36 -0600 In-Reply-To: <412C96EC.8050400@intertwingly.net> References: <200408231547.BOE99812@ms8.netsolmail.com> <412BC0C3.20407@intertwingly.net> <82777bea04082501091a292784@mail.gmail.com> <412C96EC.8050400@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5A76B808-F6A0-11D8-8422-000A959A17A6@cursive.net> Content-Transfer-Encoding: 7bit Cc: Peter Saint-Andre , atom-syntax@imc.org, Joe Hildebrand From: Joe Hildebrand Subject: Re: Transporting Atom Notifications over the XMLPP Date: Wed, 25 Aug 2004 08:09:18 -0600 To: Sam Ruby X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 25 Aug 2004 16:50:36.0310 (UTC) FILETIME=[A4E76360:01C48AC3] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is as good a forum as any to discuss it, and we're certainly willing to make mods to suit the community on both sides. On your options: 1) this would work. I don't see any downside, but it's pretty hard to enforce. 2) I don't think this is right. No need for yet another GUID-y thing in the world. 3) This is probably right. For example, I wouldn't want to have people look at the pub/sub ID and not the atom:id in order to do uniqueness checks. That would be a layering problem. -- Joe Hildebrand Denver, CO, USA On Aug 25, 2004, at 7:41 AM, Sam Ruby wrote: > > Joe Hildebrand wrote: > >> Without addressing the formatting issues associated with atom:id's, >> yes, I think it would be useful to use the atom:id as the pubsub item >> ID. Item ID's have the nice property that if I publish another item >> with the same ID, the old item gets replaced. > > What's the process for getting draft-saintandre-atompub-notify updated? > > I see three basic approaches, which I will list in my order of > preference: > > 1) decide that the pubsub item ID MUST be the same as the atom:id when > transporting Atom notifications over the XMLPP. > > 2) decide that atom:id and pubsub item ID are orthogonal concepts and > discourage (either implicitly via examples, or explicitly via prose) > these concepts from being confused. > > 3) decide that atom:id SHOULD be used as the pubsub item ID, but that > consumers MUST NOT presume that they are the same. > > - Sam Ruby > From owner-atom-syntax@mail.imc.org Wed Aug 25 13:07:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01272 for ; Wed, 25 Aug 2004 13:07:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGrYSW064284; Wed, 25 Aug 2004 09:53:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PGrY2h064283; Wed, 25 Aug 2004 09:53:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGrWLn064257 for ; Wed, 25 Aug 2004 09:53:33 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1f2ed5cd040825093474710cae@mail.gmail.com> References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> <1f2ed5cd040825093474710cae@mail.gmail.com> Date: Wed, 25 Aug 2004 09:53:36 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:34 PM +0200 8/25/04, Danny Ayers wrote: >But if you look back to the start of the del.icio.us thread the issue >raised was that Atom couldn't do something that RSS/RDF could. In or >out of of scope? In scope. Some of the recent discussion has the strong scent of "re-hash", but it hasn't been beaten to death yet. Specific proposals, done as paces, might be appropriate right about now... --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 25 13:08:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01318 for ; Wed, 25 Aug 2004 13:08:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGrXNR064273; Wed, 25 Aug 2004 09:53:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PGrXMG064272; Wed, 25 Aug 2004 09:53:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PGrWLl064257 for ; Wed, 25 Aug 2004 09:53:33 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <2B9035AF-F6B3-11D8-ADE0-000A95D9FA7A@bblfish.net> References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> <2B9035AF-F6B3-11D8-ADE0-000A95D9FA7A@bblfish.net> Date: Wed, 25 Aug 2004 09:48:00 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:23 PM +0200 8/25/04, Henry Story wrote: >I myself think that this RDF issue should be re-opened, because I >have not yet seen any good arguments against it and it is fully >supported by the founder of the web himself, Tim Berner's Lee. If >that is not a good enough pedigree for an idea I don't know what is. Pedigree is worth something, but not so much, in the IETF. Even Vint Cerf has made some proposals that have not been adopted. You need: - A clear and precise proposal - A handful of backers who have been active so far this WG - An expectation of backlash If have those things, bring them as a package to the mailing list. >If Dare Obansanjo has to rewrite a few scripts if we find we have to >change things, then I can just say I am very sorry for him. But this >is a forum for creating a powerful, top notch, earth chattering >protocol, or else everyone here is just wasting everyone else's time. Fully disagree. We don't need to shatter anything in order to succeed well. We to come up with a set of protocols that are clear, clean, extensible, and will stand up well to a decade or more of unpredictable change around them. There are many ways to get there. Being unwilling to change one's mind, feeling superior to others, and making personal attacks is one way. My experience in the IETF leads me to think that there are better ways that, when used, lead to better protocols because more people have actively participated and fewer people have been driven away. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Aug 25 13:12:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01787 for ; Wed, 25 Aug 2004 13:12:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PH5K1S066917; Wed, 25 Aug 2004 10:05:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PH5Kcb066914; Wed, 25 Aug 2004 10:05:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PH5JWf066903; Wed, 25 Aug 2004 10:05:20 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 08B6D4F31C; Wed, 25 Aug 2004 13:05:23 -0400 (EDT) Date: Wed, 25 Aug 2004 13:05:23 -0400 From: Dan Brickley To: Danny Ayers Cc: Paul Hoffman / IMC , Atom WG Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Message-ID: <20040825170522.GL20056@homer.w3.org> References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> <1f2ed5cd040825093474710cae@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f2ed5cd040825093474710cae@mail.gmail.com> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Danny Ayers [2004-08-25 18:34+0200] > > On Wed, 25 Aug 2004 08:50:25 -0700, Paul Hoffman / IMC wrote: > > > It would be a very major shift for this WG to change the Atom format > > to RDF. If someone wants to make a proposal for that, they should > > have a list of at least three active WG members as co-proponents > > before starting the discussion. Further, they should expect a fair > > amount of criticism for re-hashing old arguments. Absent an active > > proposal, discussing advantages of RDF or other significant base > > changes is out of scope. > > I fully accept that the Atom format isn't going to be RDF/XML, and > that there won't be a normative RDF model for Atom. Likewise I'm not expecting Atom to use RDF/XML for its syntax. Re 'normative RDF model', I didn't realise the model / extensibility issue was closed yet, and Sam's reply to my message last week left me thinking that RDF's datamodel (though not the XML notation) might still prove useful to Atom. Whether that happens depends on the extent of Atom's ambitions regarding extensibility beyond the blog-centric core. BTW I apologise for starting that big thread last week then dropping off the planet (actually I was in the N etherlands, but in meetings and offline). I'm trying to catch up on that thread this week, will try not to rehash old debates. Regarding concrete proposals, I proposed that the http://nature.com/rss/ Jobs use case be taken on board by this WG as 'something we could try to make sure was do-able in Atom'. I guess I should go read up on the proper process for articulating that request. BTW I hope my contributions last week made clear that I'm not in the (empty AFAIK) 'RDF will solve all problems' camp. It's just the only way I know of to do decentralised, loosly coordinated and fine-grained namespace mixing. I'm very open to their being other ways to do this in XML, I just haven't encountered any yet. Dan From owner-atom-syntax@mail.imc.org Wed Aug 25 13:14:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01934 for ; Wed, 25 Aug 2004 13:14:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PH7Oow067300; Wed, 25 Aug 2004 10:07:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PH7O1K067299; Wed, 25 Aug 2004 10:07:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PH7Np9067285; Wed, 25 Aug 2004 10:07:23 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7PH7Qil025718; Wed, 25 Aug 2004 11:07:26 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3000JB4I8E85@edgemail1.Central.Sun.COM>; Wed, 25 Aug 2004 11:07:26 -0600 (MDT) Received: from [192.168.1.15] ([216.113.203.45]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I30003PFI8DL2@mail.sun.net>; Wed, 25 Aug 2004 11:07:26 -0600 (MDT) Date: Wed, 25 Aug 2004 10:07:21 -0700 From: Tim Bray Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] In-reply-to: <2B9035AF-F6B3-11D8-ADE0-000A95D9FA7A@bblfish.net> To: Henry Story Cc: Danny Ayers , Atom Syntax , Paul Hoffman / IMC , =?ISO-8859-1?Q?Bill_de_h=D3ra?= Message-id: <3A45834F-F6B9-11D8-84A8-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> <2B9035AF-F6B3-11D8-ADE0-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 25, 2004, at 9:23 AM, Henry Story wrote: > I don't think that Danny was proposing to shift to RDF. He was in fact > putting forward an extremely minimalist proposal Sorry, I was having trouble keeping up with that thread. Is there a Pace from Danny or someone capturing the proposal? The delic.io.us use-case is potentially instructive. > I myself think that this RDF issue should be re-opened So re-open it. Write a Pace, see if you can build consensus around it. -Tim From owner-atom-syntax@mail.imc.org Wed Aug 25 13:27:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03100 for ; Wed, 25 Aug 2004 13:27:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHLjbi070686; Wed, 25 Aug 2004 10:21:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PHLj8F070685; Wed, 25 Aug 2004 10:21:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PHLjHO070662 for ; Wed, 25 Aug 2004 10:21:45 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825172143.21590.qmail@web41214.mail.yahoo.com> Received: from [24.18.130.238] by web41214.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 10:21:43 PDT Date: Wed, 25 Aug 2004 10:21:43 -0700 (PDT) From: Dare Obasanjo Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] To: Sam Ruby Cc: Atom WG In-Reply-To: <412CBD05.6020307@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Sam Ruby wrote: > > > Heck, a straightforward solution would be just to > use > > XLink or define some profile of XLink to use in > Atom. > > The only problem seems to be that no one wants to > step > > up to the plate and do it. I'm not interested > enough > > in the problem to spend time on it but that seems > like > > a decent solution. > > At the moment, the Atom link element is modelled > after the HTML link > tag[3], which has a number of advantages[4]. Yes, if all the links have similar semantics. Specifically what comes to mind is if as a fallback they can all be rendered as human clickable links. In fact, that simple guideline is probably all that is really needed in the Atom case. Although it will mean that for consistency that Atom shouldn't use atom:link for the various service URIs which doesn't seem like a bad tradeoff to me. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 25 13:37:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03721 for ; Wed, 25 Aug 2004 13:37:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHTjYe072205; Wed, 25 Aug 2004 10:29:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PHTjXu072204; Wed, 25 Aug 2004 10:29:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from journurl.com (69-56-184-50.theplanet.com [69.56.184.50] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHTiVX072176 for ; Wed, 25 Aug 2004 10:29:44 -0700 (PDT) (envelope-from roger@agincourtmedia.com) Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Wed, 25 Aug 2004 12:29:38 -0500 From: "Roger B." To: "'Atom Syntax'" Subject: RE: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Date: Wed, 25 Aug 2004 12:32:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <2B9035AF-F6B3-11D8-ADE0-000A95D9FA7A@bblfish.net> thread-index: AcSKwAZ2DBqQFG8UReCA+OyFhzDNqAAB1gVA Message-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > But this is > a forum for creating a powerful, top notch, earth chattering protocol... Henry: Atom is an alternative to RSS and the Blogger/Metaweblog API... I dunno about you, but that doesn't quite meet my standard for earth shattering. Nor was the destruction of worlds on most folks' Atom implementation agenda, last I looked. Except maybe Dare. What with all of his evil overlord plans and all. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Wed Aug 25 13:38:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03853 for ; Wed, 25 Aug 2004 13:38:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHW6PU072721; Wed, 25 Aug 2004 10:32:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PHW6ZF072720; Wed, 25 Aug 2004 10:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHW5mq072693 for ; Wed, 25 Aug 2004 10:32:06 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so187714rnb for ; Wed, 25 Aug 2004 10:32:04 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2239047rnh; Wed, 25 Aug 2004 10:32:04 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 10:32:04 -0700 (PDT) Message-ID: <1f2ed5cd04082510322cd3a921@mail.gmail.com> Date: Wed, 25 Aug 2004 19:32:04 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dan Brickley Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Cc: Paul Hoffman / IMC , Atom WG In-Reply-To: <20040825170522.GL20056@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> <1f2ed5cd040825093474710cae@mail.gmail.com> <20040825170522.GL20056@homer.w3.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 13:05:23 -0400, Dan Brickley wrote: > * Danny Ayers [2004-08-25 18:34+0200] > Re 'normative RDF model', I didn't realise the model / extensibility > issue was closed yet, Sorry, it probably isn't - I read too much into Paul's post. > and Sam's reply to my message last week > left me thinking that RDF's datamodel (though not the XML notation) > might still prove useful to Atom. You're not alone. I know I'm not the only one who wanted RDF through-and-through, but also I believe several of the folks who were adamantly against RDF/XML syntax are actually pro-model. (See Mark P's. article of a year ago (!) : "So is the RDF model a good thing? I think that it is; considering it made our format better, regardless of the syntax." [1]). Whether that happens depends > on the extent of Atom's ambitions regarding extensibility beyond the > blog-centric core. BTW I apologise for starting that big thread > last week then dropping off the planet (actually I was in the N > etherlands, but in meetings and offline). I'm trying to catch up on > that thread this week, will try not to rehash old debates. Regarding > concrete proposals, I proposed that the http://nature.com/rss/ Jobs use > case be taken on board by this WG as 'something we could try to make > sure was do-able in Atom'. I guess I should go read up on the proper > process for articulating that request. If doing the kind of things RSS 1.0 could do actually is in scope, then I'd add as a use case the growing number of RSS 1.0 feeds (such as [2], [3]) that identifier authors/contributors using FOAF. Whatever that is ;-) Cheers, Danny. [1] http://www.xml.com/pub/a/2003/08/20/dive.html [2] http://feeds.feedburner.com/BenHammersleysDangerousPrecedent [3] http://www.wasab.dk/morten/blog/feed/rdf From owner-atom-syntax@mail.imc.org Wed Aug 25 13:43:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04178 for ; Wed, 25 Aug 2004 13:43:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHZ3Hl073277; Wed, 25 Aug 2004 10:35:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PHZ39W073276; Wed, 25 Aug 2004 10:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PHZ0Le073234 for ; Wed, 25 Aug 2004 10:35:02 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825173458.24427.qmail@web41214.mail.yahoo.com> Received: from [24.18.130.238] by web41214.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 10:34:58 PDT Date: Wed, 25 Aug 2004 10:34:58 -0700 (PDT) From: Dare Obasanjo Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] To: Dan Brickley , Danny Ayers Cc: Paul Hoffman / IMC , Atom WG In-Reply-To: <20040825170522.GL20056@homer.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Dan Brickley wrote: > > Regarding > concrete proposals, I proposed that the > http://nature.com/rss/ Jobs use > case be taken on board by this WG as 'something we > could try to make > sure was do-able in Atom'. I guess I should go read > up on the proper > process for articulating that request. I don't see a use case articulated at the end of that link just links to a bunch of RSS 1.0 feeds with some extension elements from the Nature Jobs namespace. To articulate a use case I'd expect to hear what information the producer would like put in the feed and what is expected for consumers to do with that information. > BTW I hope my contributions last week made clear > that I'm not in the (empty > AFAIK) 'RDF will solve all problems' camp. It's just > the only way I know > of to do decentralised, loosly coordinated and > fine-grained namespace mixing. > I'm very open to their being other ways to do this > in XML, I just haven't > encountered any yet. Sounds like a contradiction. How can you claim to be open minded if you've already decided that 'RDF is the only way'? Also I'm not sure what is meant here by namespace mixing. Mixing the syntax of two XML vocabularies can be done with strcat() in C. However I'm sure that's not what you mean. So what do you mean? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 25 14:03:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05584 for ; Wed, 25 Aug 2004 14:03:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHsulQ077417; Wed, 25 Aug 2004 10:54:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PHsuqZ077414; Wed, 25 Aug 2004 10:54:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PHstwi077398 for ; Wed, 25 Aug 2004 10:54:55 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so171236rnb for ; Wed, 25 Aug 2004 10:54:55 -0700 (PDT) Received: by 10.38.1.62 with SMTP id 62mr2245265rna; Wed, 25 Aug 2004 10:54:55 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 10:54:55 -0700 (PDT) Message-ID: <1f2ed5cd040825105412f3c4f2@mail.gmail.com> Date: Wed, 25 Aug 2004 19:54:55 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Cc: Henry Story , Danny Ayers , Atom Syntax , Paul Hoffman / IMC , "Bill de hÓra" In-Reply-To: <3A45834F-F6B9-11D8-84A8-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825144347.61477.qmail@web41210.mail.yahoo.com> <412CACF6.7020000@dehora.net> <2B9035AF-F6B3-11D8-ADE0-000A95D9FA7A@bblfish.net> <3A45834F-F6B9-11D8-84A8-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 10:07:21 -0700, Tim Bray wrote: > > On Aug 25, 2004, at 9:23 AM, Henry Story wrote: > > > I don't think that Danny was proposing to shift to RDF. He was in fact > > putting forward an extremely minimalist proposal > > Sorry, I was having trouble keeping up with that thread. Is there a > Pace from Danny or someone capturing the proposal? http://www.intertwingly.net/wiki/pie/PaceLinkRelMechanism From owner-atom-syntax@mail.imc.org Wed Aug 25 14:24:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07050 for ; Wed, 25 Aug 2004 14:24:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIGJWO081307; Wed, 25 Aug 2004 11:16:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PIGJI5081306; Wed, 25 Aug 2004 11:16:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIGGNs081263 for ; Wed, 25 Aug 2004 11:16:19 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so122236rnl for ; Wed, 25 Aug 2004 11:16:15 -0700 (PDT) Received: by 10.38.206.33 with SMTP id d33mr245408rng; Wed, 25 Aug 2004 11:16:15 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 11:16:15 -0700 (PDT) Message-ID: <1f2ed5cd0408251116b4815f8@mail.gmail.com> Date: Wed, 25 Aug 2004 20:16:15 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Mark Pilgrim Subject: Re: PaceEquivalents Cc: Paul Hoffman / IMC , Atom WG In-Reply-To: <14be96d3040825061141c9ec63@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <14be96d3040824075565ef4da1@mail.gmail.com> <1f2ed5cd04082505156a8d236b@mail.gmail.com> <14be96d3040825061141c9ec63@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 09:11:23 -0400, Mark Pilgrim wrote: > > True, although perhaps you have that the wrong way around - the core > > terms in FOAF haven't changed in 3+ years > > Quoting from : [snip] See also: http://web.archive.org/web/20010605211618/http://xmlns.com/foaf/0.1/ > IIRC, most of the contention centered around the vagueness of the DC > terms. Does "issued" mean "first-issued" or "most-recently-issued"? > Can it mean "re-issued"? Does "modified" mean any modification, or > just "significant" modification? The proposal is to provide additional information to developers that may help them work with Atom, for example refactoring their RSS 1.0 feeds. So ok, perhaps what is needed is a note to say that the Atom terms are specializations of the corresponding DC terms, so that inappropriate mappings aren't made. Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Aug 25 14:29:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07357 for ; Wed, 25 Aug 2004 14:29:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIKc2J082769; Wed, 25 Aug 2004 11:20:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PIKc8a082768; Wed, 25 Aug 2004 11:20:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PIKc3X082745 for ; Wed, 25 Aug 2004 11:20:38 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825182036.83573.qmail@web41202.mail.yahoo.com> Received: from [24.18.130.238] by web41202.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 11:20:36 PDT Date: Wed, 25 Aug 2004 11:20:36 -0700 (PDT) From: Dare Obasanjo Subject: PaceLinkRelMechanism To: Danny Ayers , Tim Bray Cc: Henry Story , Danny Ayers , Atom Syntax , Paul Hoffman / IMC , Bill de "hÓra" In-Reply-To: <1f2ed5cd040825105412f3c4f2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Danny Ayers wrote: > http://www.intertwingly.net/wiki/pie/PaceLinkRelMechanism Besides defining a syntax for link elements I'm not sure what else is in this Pace. Below are some questions about aspects of the Pace [If namespaces are used as described, the link element can be mapped onto RDF properties, providing a huge gain in interoperability and existing properties (such as foaf:depiction in the example below) could immediately be used within Atom. ] Can you explain how these gains in interoperability manifest themselves. For example, how does Bloglines or RSS Bandit reap these supposed gains in interoperability in comparison to just sticking a element in the feed? [Note that the 'href' name might be less than ideal - most of the time this won't be a clickable link. ] So this means that I can't even fallback on the default behavior of rendering every atom:link not understood as a clickable link in the UI? OK, I guess I now see where this proposal is going. It's tailored towards the RDF scenario. Most aggregators will ignore unknown links the same way they do unknown elements but SemWeb aware applications could use RDF/OWL/etc to somehow learn what to do with such data. I dislike this Pace because it violates the principle of least surprise. Basically atom:link elements would in many cases not actually be human clickable links which to many would be unexpected. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Wed Aug 25 14:30:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07406 for ; Wed, 25 Aug 2004 14:30:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PI9rTx080116; Wed, 25 Aug 2004 11:09:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PI9rDA080115; Wed, 25 Aug 2004 11:09:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41211.mail.yahoo.com (web41211.mail.yahoo.com [66.218.93.44]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PI9q2t080078 for ; Wed, 25 Aug 2004 11:09:52 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825180951.75763.qmail@web41211.mail.yahoo.com> Received: from [24.18.130.238] by web41211.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 11:09:51 PDT Date: Wed, 25 Aug 2004 11:09:51 -0700 (PDT) From: Dare Obasanjo Subject: Framing the Extensibility Discussion To: atom-syntax@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It seems best to properly frame what the goals of extensibilty should be before debating various techniques for achieving this in Atom. When I client encounters content in an Atom feed it doesn't understand it can do one of three things 1.) Ignore it 2.) Treat it in some default manner 3.) Learn how to consume this content The RSS approach has been to do (1). It looks like the goal of the folks championing link extensibility is so that in some cases one could do (2). However no one has put forward what this default treatment should be nor what the connection should be between such extensions that allows them to be treated the same. The Semantic Web approach is (3). My personal opinion is that this is a pipe dream but I suspect some in the RDF camp belive otherwise even though so far it hasn't been shown to occur in the wild outside of demoware. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 25 14:33:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07708 for ; Wed, 25 Aug 2004 14:33:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIF4PI081088; Wed, 25 Aug 2004 11:15:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PIF44M081087; Wed, 25 Aug 2004 11:15:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIF34h081073 for ; Wed, 25 Aug 2004 11:15:03 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C02I3-000638-P7; Wed, 25 Aug 2004 18:14:31 +0000 Message-ID: <412CD700.7080001@franklinmint.fm> Date: Wed, 25 Aug 2004 14:14:24 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: bob@wyman.us, "'Mark Pilgrim'" , "'Dare Obasanjo'" , "'Sam Ruby'" , "'Atom WG'" Subject: PaceLinkDelicious (was: Can atom be Del.icio.us? Or, can Del.icio.us be atomic?) References: <200408212130.BOB20139@ms8.netsolmail.com> <412A1D45.1070809@franklinmint.fm> <2111607.1093282923443.JavaMail.dtcd@mac.com> In-Reply-To: <2111607.1093282923443.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > > On Monday, August 23, 2004, at 12:50PM, Robert Sayre wrote: > >>What are some possible approaches for this feature? I can imagine an >> link. > > > Mark Pilgrim's excellent proposal is here: > http://www.xml.com/lpt/a/2004/06/16/dive.html > > Someone write a Pace. Shrook already supports related and via links*. http://www.intertwingly.net/wiki/pie/PaceLinkDelicious Rationale ---------------- The current Atom Link values are not expressive enough for current use cases. See: Can atom be Del.icio.us?[0] There is No FAQ [1] Proposal ---------------- Keep a link with @rel value "alternate" mandatory, but allow a single link @rel value of "about" to also be present. Add an additional @rel value of "related" to allow links to additional resources. This proposal is not advocating a particular syntax or extensibility approach for Link Constructs. It uses the method specified in the current draft. The small changes to the spec can be found on the wiki page. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg08730.html [1] http://www.intertwingly.net/blog/1494.html From owner-atom-syntax@mail.imc.org Wed Aug 25 14:38:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08048 for ; Wed, 25 Aug 2004 14:38:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIVC1Y084648; Wed, 25 Aug 2004 11:31:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PIVCVw084647; Wed, 25 Aug 2004 11:31:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIVBd8084631; Wed, 25 Aug 2004 11:31:11 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7PIVE53002449; Wed, 25 Aug 2004 12:31:14 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I30004YKM42CC@edgemail1.Central.Sun.COM>; Wed, 25 Aug 2004 12:31:14 -0600 (MDT) Received: from [192.168.1.2] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I30003HXM41L5@mail.sun.net>; Wed, 25 Aug 2004 12:31:14 -0600 (MDT) Date: Wed, 25 Aug 2004 11:31:09 -0700 From: Tim Bray Subject: Re: PaceLinkRelMechanism In-reply-to: <20040825182036.83573.qmail@web41202.mail.yahoo.com> To: Dare Obasanjo Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Henry Story , Atom Syntax , Paul Hoffman / IMC , Danny Ayers , Danny Ayers Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040825182036.83573.qmail@web41202.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 25, 2004, at 11:20 AM, Dare Obasanjo wrote: > http://www.intertwingly.net/wiki/pie/PaceLinkRelMechanism > > Besides defining a syntax for link elements I'm not > sure what else is in this Pace. Below are some > questions about aspects of the Pace It seems like a straightforward trade-off... do you have a small set of link types that are wired right into the Atom vocabulary, or do you consciously put an extensibility point around link types? If you want the latter, the mechanism here is OK (except for qnames in attribute values, which are a horrible, broken idea even if the HTML working group wants to use them). I think the delic.io.us use-case throws a nice useful highlight on this one; does this type of link deserve its own special built-in markup ("about" rather than "alternative"), or is it evidence of the fact that there are an unbounded number of interesting link types, so we should go for extensibility? My personal leaning would be for the former, but I can certainly see both sides of the argument. -Tim From owner-atom-syntax@mail.imc.org Wed Aug 25 14:43:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08469 for ; Wed, 25 Aug 2004 14:43:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PILoba082978; Wed, 25 Aug 2004 11:21:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PILoRr082977; Wed, 25 Aug 2004 11:21:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PILn4f082971 for ; Wed, 25 Aug 2004 11:21:49 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7PILsvv002140; Wed, 25 Aug 2004 14:21:55 -0400 Message-ID: <412CD8BF.5060403@intertwingly.net> Date: Wed, 25 Aug 2004 14:21:51 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Atom WG Subject: Link requirements [was : Can atom be Del.icio.us?] References: <20040825172143.21590.qmail@web41214.mail.yahoo.com> In-Reply-To: <20040825172143.21590.qmail@web41214.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: >> >>At the moment, the Atom link element is modelled >>after the HTML link >>tag[3], which has a number of advantages[4]. > > Yes, if all the links have similar semantics. > Specifically what comes to mind is if as a fallback > they can all be rendered as human clickable links. In > fact, that simple guideline is probably all that is > really needed in the Atom case. Although it will mean > that for consistency that Atom shouldn't use atom:link > for the various service URIs which doesn't seem like a > bad tradeoff to me. Let's see if I can capture that and see if there is a basis that we can build upon. With a mental model of something html link-ish (leaving open the possibility to a number of tweaks), which of the following can we agree upon? (1) Each atom:entry element must have one or more link elements associated with it. (2) Exactly one of those link elements is to be considered the 'primary' or 'default' link. (3) href attributes specify the location of a Web resource, thus defining a link between the current entry (the source anchor) and the destination anchor defined by this attribute. (4) For those hrefs which are http, consumers can assume that http GET is supported for that uri. Such GET requests are likely to return results with the mime type indicated by the type attribute. Now, looking at Mark's http://www.xml.com/lpt/a/2004/06/16/dive.html, (5) Exactly one of those link elements is to be considered a 'permalink'. (6) Linking to related articles is a valid use case for this element. (7) Linking to sources is a valid use case for this element (8) Linking to comment feeds is a valid use case for this element (9) Linking to next/previous archives is a valid use case for this element (10) Linking to service interfaces is a valid use case for this element Notes: a) I intentionally split out (2) and (5) based on the prior discussion about the virtues of being vague/versatile. b) It is not clear to me that (4) and (10) are mutually exclusive. c) Extensibility is a separate discussion. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 25 14:49:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08863 for ; Wed, 25 Aug 2004 14:49:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIeDVu086559; Wed, 25 Aug 2004 11:40:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PIeDh3086558; Wed, 25 Aug 2004 11:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIeCmc086538 for ; Wed, 25 Aug 2004 11:40:13 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id CAE25171D96; Wed, 25 Aug 2004 14:40:09 -0400 (EDT) Reply-To: From: "Bob Wyman" To: Subject: Atom over XMPP -- PubSub sidebar beta now available Date: Wed, 25 Aug 2004 14:38:09 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSK0qtBNt7IP1vFRteS+JjUQDiD1g== Message-Id: <20040825184009.CAE25171D96@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In order to demonstrate the benefits of transferring Atom over XMPP, I invite you to download and experiment with our new "PubSub Sidebar". The PubSub SideBar is an Explorer Bar extension of Windows Internet Explorer. The PubSub SideBar allows you to monitor in near real-time the discussions in over 2.5 million blogs while browsing the Internet freely. PubSub.com pushes new Atom entries which match a user's "subscription" to the PubSub SideBar as soon as they are discovered. This initial beta version of the sidebar is targeted at political/election news junkies who want to be the first to hear election gossip, news, etc. Thus, a "Sample" account[1] is provided that contains subscriptions for such keywords as "John Kerry", "George Bush" and "Republican National Convention." There is no faster way than using Atom over XMPP to keep up-to-date on what bloggers are saying about the US Presidential candidates and the issues of this election. This version of the PubSub Sidebar requires either Windows 2000 or XP with the .NET Framework 1.1 to be installed. To download the sidebar, go to: http://pubsub.com/sidebar Note: Some users may need to reboot in order to get the sidebar to work in Windows Explorer. Existing PubSub.com users can access their personal PubSub subscriptions by simply logging in using the email address and password that they already use to access their accounts on PubSub.com. Information on the protocol used to power this application can be found at: http://pubsub.com/developers . That page also includes links to an open source implementation of a similar, but stand-alone, application. This application is free -- there is no charge for using it or the PubSub service. I hope you enjoy using it and hope that it will help demonstrate the value of feeding Atom entries over XMPP. bob wyman [1] The username is "sample@pubsub.com". The password is: "sample". From owner-atom-syntax@mail.imc.org Wed Aug 25 14:53:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09239 for ; Wed, 25 Aug 2004 14:53:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIhZdU087029; Wed, 25 Aug 2004 11:43:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PIhZjd087028; Wed, 25 Aug 2004 11:43:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIhYdu087019 for ; Wed, 25 Aug 2004 11:43:34 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C02kB-000357-P6; Wed, 25 Aug 2004 18:43:35 +0000 Message-ID: <412CDDD3.7070002@franklinmint.fm> Date: Wed, 25 Aug 2004 14:43:31 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Dare Obasanjo , Atom WG Subject: Re: Link requirements [was : Can atom be Del.icio.us?] References: <20040825172143.21590.qmail@web41214.mail.yahoo.com> <412CD8BF.5060403@intertwingly.net> In-Reply-To: <412CD8BF.5060403@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > > (4) For those hrefs which are http, consumers can assume that http GET > is supported for that uri. Such GET requests are likely to return > results with the mime type indicated by the type attribute. > > (10) Linking to service interfaces is a valid use case for this element > > > b) It is not clear to me that (4) and (10) are mutually exclusive. > I think @href is a misnomer for service interfaces. They aren't hypertext. They are "logical information ... not intended to be browsed by people as a document." [0] Robert Sayre [0] http://www.w3.org/DesignIssues/XLink.html From owner-atom-syntax@mail.imc.org Wed Aug 25 14:55:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09353 for ; Wed, 25 Aug 2004 14:55:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIn0ht087771; Wed, 25 Aug 2004 11:49:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PIn02n087770; Wed, 25 Aug 2004 11:49:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PImxOV087758 for ; Wed, 25 Aug 2004 11:48:59 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 55367 invoked from network); 25 Aug 2004 18:48:57 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 25 Aug 2004 18:48:57 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412CDF25.4090206@internetalchemy.org> Date: Wed, 25 Aug 2004 19:49:09 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: atom-syntax@imc.org Subject: Re: Framing the Extensibility Discussion References: <20040825180951.75763.qmail@web41211.mail.yahoo.com> In-Reply-To: <20040825180951.75763.qmail@web41211.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25/08/2004 19:09, Dare Obasanjo wrote: > When I client encounters content in an Atom feed it > doesn't understand it can do one of three things > > 1.) Ignore it > 2.) Treat it in some default manner > 3.) Learn how to consume this content I think 3 here is meaningless. I would suggest: 4. Discover if part or all of extension can safely be treated as something the client already knows how to handle You could potentially discover that some unknown link types should be displayed to the user and that others are for system use only by referring to some kind of inheritance mechanism. Ian From owner-atom-syntax@mail.imc.org Wed Aug 25 15:08:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10024 for ; Wed, 25 Aug 2004 15:08:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIrSxI088356; Wed, 25 Aug 2004 11:53:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PIrS6N088355; Wed, 25 Aug 2004 11:53:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PIrRsw088341 for ; Wed, 25 Aug 2004 11:53:28 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so173747rnb for ; Wed, 25 Aug 2004 11:53:31 -0700 (PDT) Received: by 10.38.1.62 with SMTP id 62mr2269527rna; Wed, 25 Aug 2004 11:53:31 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 11:53:30 -0700 (PDT) Message-ID: <1f2ed5cd0408251153319d3d9c@mail.gmail.com> Date: Wed, 25 Aug 2004 20:53:30 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceLinkRelMechanism Cc: Tim Bray , Henry Story , Danny Ayers , Atom Syntax , Paul Hoffman / IMC , bill@dehora.net In-Reply-To: <20040825182036.83573.qmail@web41202.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825182036.83573.qmail@web41202.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 11:20:36 -0700 (PDT), Dare Obasanjo wrote: > > --- Danny Ayers wrote: > > > http://www.intertwingly.net/wiki/pie/PaceLinkRelMechanism > > Besides defining a syntax for link elements I'm not > sure what else is in this Pace. It defines a mechanism for their interpretation. > Below are some > questions about aspects of the Pace > > [If namespaces are used as described, the link element > can be mapped onto RDF properties, providing a huge > gain in interoperability and existing properties (such > as foaf:depiction in the example below) could > immediately be used within Atom. ] > > Can you explain how these gains in interoperability > manifest themselves. For example, how does Bloglines > or RSS Bandit reap these supposed gains in > interoperability in comparison to just sticking a > element in the feed? The most immediate gains are disambiguation and code reuse. If you stick a in the feed, say underneath an how should it be interpreted? Using you would know that this related to the parent rather than any other elements (such as the ). The same dispatching code (to trigger behaviour) can be used for all extensions of this structure. The data structure doesn't in itself provide the semantics, it just makes it easier to define and interpret. > [Note that the 'href' name might be less than ideal - > most of the time this won't be a clickable link. ] > > So this means that I can't even fallback on the > default behavior of rendering every atom:link not > understood as a clickable link in the UI? Given the broad range of interpretation/behaviour already suggested for , that would probably be a bad idea. > OK, I guess I now see where this proposal is going. > It's tailored towards the RDF scenario. Most > aggregators will ignore unknown links the same way > they do unknown elements but SemWeb aware applications > could use RDF/OWL/etc to somehow learn what to do with > such data. I wouldn't say it was tailored towards the RDF scenario, although it does share the idea of a binary relation between web resources. Forget RDF. Consider what code you might need to write to support some other extensions. Not just one extension, lots. Look for common features in those extensions. I bet you'll find a lot of -link structures. All this is really about is expressing a very common data structure in as unambiguous a fashion as possible. > I dislike this Pace because it violates the principle > of least surprise. Basically atom:link elements would > in many cases not actually be human clickable links > which to many would be unexpected. How many of the current values for 'rel' in link would be appropriate for hyperlinks? What about HTML's element - does that come as a surprise? Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Aug 25 15:11:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10278 for ; Wed, 25 Aug 2004 15:11:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJ3x6k089953; Wed, 25 Aug 2004 12:03:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PJ3xZs089948; Wed, 25 Aug 2004 12:03:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJ3woU089926 for ; Wed, 25 Aug 2004 12:03:58 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so124469rnl for ; Wed, 25 Aug 2004 12:03:57 -0700 (PDT) Received: by 10.38.206.33 with SMTP id d33mr265702rng; Wed, 25 Aug 2004 12:03:57 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 12:03:57 -0700 (PDT) Message-ID: <1f2ed5cd040825120331e354fc@mail.gmail.com> Date: Wed, 25 Aug 2004 21:03:57 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: PaceLinkRelMechanism Cc: Dare Obasanjo , "Bill de hÓra" , Henry Story , Atom Syntax , Paul Hoffman / IMC , Danny Ayers In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825182036.83573.qmail@web41202.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > It seems like a straightforward trade-off... do you have a small set of > link types that are wired right into the Atom vocabulary, or do you > consciously put an extensibility point around link types? Exactly. If you want > the latter, the mechanism here is OK (except for qnames in attribute > values, which are a horrible, broken idea even if the HTML working > group wants to use them). I agree re. the qnames, but the horse has pretty well bolted, and I think pragmatism beats purity here - it's easier than the RFC 2731 mechanism. In any case, if XHTML gets them, Atom will get them in its content whether we approve or not. I think the delic.io.us use-case throws a > nice useful highlight on this one; does this type of link deserve its > own special built-in markup ("about" rather than "alternative"), or is > it evidence of the fact that there are an unbounded number of > interesting link types, so we should go for extensibility? My personal > leaning would be for the former, but I can certainly see both sides of > the argument. -Tim The delic.io.us use-case is just the latest in a long series of suggested additions to the 'rel' list. But in any case, we can have both - add "about" to the core rather than as a (namespace-qualified) extension. Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Aug 25 15:21:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11409 for ; Wed, 25 Aug 2004 15:21:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJB6fi091485; Wed, 25 Aug 2004 12:11:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PJB645091484; Wed, 25 Aug 2004 12:11:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJB5hM091462 for ; Wed, 25 Aug 2004 12:11:06 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004082519110301600jt79le>; Wed, 25 Aug 2004 19:11:04 +0000 Date: Wed, 25 Aug 2004 13:11:01 -0600 Subject: Re: Link requirements [was : Can atom be Del.icio.us?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <412CD8BF.5060403@intertwingly.net> Message-Id: <81395121-F6CA-11D8-AFC5-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, August 25, 2004, at 12:21 PM, Sam Ruby wrote: > Let's see if I can capture that and see if there is a basis that we > can build upon. With a mental model of something html link-ish > (leaving open the possibility to a number of tweaks), which of the > following can we agree upon? > > (1) Each atom:entry element must have one or more link elements > associated with it. This fits current syndication usage as far as I'm aware. It's far from inconceivable that people could want to publish feed-only blogs rather than blogs with feeds, and that there could be other uses for feed-only publication, either of which may or may not not have links associated with each entry. Perhaps a good question is, if an entry doesn't have a link--if it is entirely self-contained--does anything break? Off the top of my head, I can't think of anything that that would really break. > (2) Exactly one of those link elements is to be considered the > 'primary' or 'default' link. Usually so. easy to conceive a case where there's not a 'primary' link, at least for the hypothetical feed-only blog. > (3) href attributes specify the location of a Web resource, thus > defining a link between the current entry (the source anchor) and the > destination anchor defined by this attribute. Sounds good. > (4) For those hrefs which are http, consumers can assume that http GET > is supported for that uri. Such GET requests are likely to return > results with the mime type indicated by the type attribute. I think it would be good to make it so that this is the case--anything that doesn't work this way should be in a different element. > Now, looking at Mark's http://www.xml.com/lpt/a/2004/06/16/dive.html, > > (5) Exactly one of those link elements is to be considered a > 'permalink'. Only if we don't want to support feed-only publication, and don't want to require the ability to link directly to an atom:entry. > (6) Linking to related articles is a valid use case for this element. Yes. > (7) Linking to sources is a valid use case for this element Yes. Question: do we want to be able to reference non-internet sources in a (semi)standard way? For example, vs. vs. ... vs. ... > (8) Linking to comment feeds is a valid use case for this element Yes to a link to the commen feed itself. The inteface for posting comments is a separate thing, covered by #10. > (9) Linking to next/previous archives is a valid use case for this > element Yes. > (10) Linking to service interfaces is a valid use case for this element I'd prefer a different element be used for this. From owner-atom-syntax@mail.imc.org Wed Aug 25 15:48:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13525 for ; Wed, 25 Aug 2004 15:48:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJdi7C096279; Wed, 25 Aug 2004 12:39:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PJdiUc096278; Wed, 25 Aug 2004 12:39:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJdhxu096252 for ; Wed, 25 Aug 2004 12:39:43 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id C7EE17C2ED; Wed, 25 Aug 2004 22:30:28 +0200 (CEST) To: "Julian Reschke" Cc: Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> Message-ID: Date: Wed, 25 Aug 2004 21:42:03 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412ADD0D.6020300@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 24 Aug 2004 08:15:41 +0200, Julian Reschke wrote: >> That's a good reason for requiring publishers to do the >> canonicalization and normalization (c14n11n :) and allowing consumers >> to compare atom:id char-by-char (as strings, not as URI's). > > No, that's a good reason to require just char-by-char comparison. So the Atom spec shouldn't say anything about either normalization or canonicalization as something publishers SHOULD or MUST do with their atom:id URI's? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 25 16:09:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15707 for ; Wed, 25 Aug 2004 16:09:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJpwaf098273; Wed, 25 Aug 2004 12:51:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PJpwEu098272; Wed, 25 Aug 2004 12:51:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJpwPo098248; Wed, 25 Aug 2004 12:51:58 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id D23587C2EE; Wed, 25 Aug 2004 22:42:48 +0200 (CEST) To: "Paul Hoffman / IMC" Cc: Atom-Syntax Subject: Re: DSig support in Aggregators References: <200408241715.BOI80313@ms8.netsolmail.com> <14be96d3040824102942c700b0@mail.gmail.com> <412B81E0.3080507@franklinmint.fm> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 25 Aug 2004 21:54:26 +0200 In-Reply-To: User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 24 Aug 2004 11:56:52 -0700, Paul Hoffman / IMC wrote: > Do folks here have a preference between sibling or child signatures? Optional child element is my preference. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 25 16:17:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16539 for ; Wed, 25 Aug 2004 16:17:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PK8Jom001205; Wed, 25 Aug 2004 13:08:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PK8Jrp001203; Wed, 25 Aug 2004 13:08:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PK8HAC001162 for ; Wed, 25 Aug 2004 13:08:18 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 796DA7C2EE; Wed, 25 Aug 2004 22:59:08 +0200 (CEST) Date: Wed, 25 Aug 2004 22:10:50 +0200 To: "Angus Turnbull" Subject: Re: Distributed comment/post authorisation proposal Cc: Atom-Syntax References: <002a01c484ca$4b051120$eb01a8c0@nirvana> <009901c4858c$c3328480$eb01a8c0@nirvana> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <009901c4858c$c3328480$eb01a8c0@nirvana> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 13:35:05 +1200, Angus Turnbull wrote: > Indeed, I'm aware of the Liberty Alliance. Okay. > This [...] is a simpler protocol change native to the ATOM API that > doesn't rely on a distributed network of trust, something I feel would > be really, really contentious to implement given the existing RDF vs. > XML Schema flamewars on this list! Then I'm not sure if I've understood your proposal fully. My thoughts on using the Liberty Alliance's work, is that we don't have to re-invent the wheel. Everything's already there, and being deployed in large corporations like AOL. Having exactly one, and no more, authentication mechanism for all web based services, would make everything much easier for users. The Liberty Alliance Project might be that mechanism. Your proposal, afaik, can't. > It seems my initial post has virtually sunk without a trace. Is it > considered unworkable? I'm not sure everyone understands it well enough. Write more about it. Use the wiki if you will. > Personally, I think it could be a "killer app" of ATOM syndication, as > to be honest, end-users don't really notice or care whether their > aggregator is using RSS 0.9x, 1.0, 2.0, ATOM or whatever, just as long as > it works. True. They don't care what authentication mechanism is used either, as long as it works. And as LAP is existing, working and being used, it's a good chance they'll some day have an LPA identity they can use to authenticate on a blog. > Basically, being able to post an authenticated comment from within your > aggregator of choice on any compliant blog would be a really > distinguishing feature. Indeed. > Putting in some smart server-to-server authorisation protocols could well > lead to a distributed trust/FOAF type network regardless, as a natural > evolution of the protocol. LAP does this already. Why re-invent? > Anyway, I'm out of here for now. I just wanted to float the idea and see > what happened. Hopefully one or other kind of distributed authorisation > eventually makes it into the ATOM proposal. It will probably be an extension nonetheless, so it's no rush to get it into the 1.0 release of the protocol. But it would be interesting to start looking at the different possibilities that are out there, and I think LAP solves a lot of problems if it's just implemented in enough applications. > Good luck if you do want to push a FOAF approach! I know too little about FOAF to do that, sorry. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 25 16:20:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16693 for ; Wed, 25 Aug 2004 16:20:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKAUow001580; Wed, 25 Aug 2004 13:10:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKAUup001579; Wed, 25 Aug 2004 13:10:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKAUPC001545 for ; Wed, 25 Aug 2004 13:10:30 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id C8B6C7C2EE; Wed, 25 Aug 2004 23:01:20 +0200 (CEST) To: "Anne van Kesteren" Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 25 Aug 2004 22:13:03 +0200 In-Reply-To: <4125ADB3.2060400@annevankesteren.nl> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 20 Aug 2004 09:52:19 +0200, Anne van Kesteren wrote: > I don't see why we have to treat URIs as strings. Normalizing them as > Mark Pilgrim explained[1] seems like a more sensible and correct thing > to do. I agree, but only if that burden can be put on the publisher. Consumers should be able to just do string comparison. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 25 16:28:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17243 for ; Wed, 25 Aug 2004 16:28:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKID6q003234; Wed, 25 Aug 2004 13:18:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKIDnx003233; Wed, 25 Aug 2004 13:18:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKICqn003219 for ; Wed, 25 Aug 2004 13:18:13 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 7B3EB7C2E7; Wed, 25 Aug 2004 23:09:03 +0200 (CEST) Date: Wed, 25 Aug 2004 22:20:47 +0200 To: "Sam Ruby" Subject: Re: PaceIdConstruct Cc: Atom-Syntax References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> <4125E14F.9050208@intertwingly.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4125E14F.9050208@intertwingly.net> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 20 Aug 2004 07:32:31 -0400, Sam Ruby wrote: > An Identification construct is an element whose content conveys a > permanent, universally unique identifier the parent element of the > construct. [...] Isn't it missing a word here? Shouldn't it be «...a permanent, universally unique identifier FOR the parent element...» or something? > It is not a closed list, but I think the insertion of the word "changed" > would be confusing... as the list is really realocated (with or without > change), migrated (with or without change)... Although I agree with Mark's comment, I agree with your assertions as well. It should try to include all kinds of re-allocations, changes etc. to the feed or entry -- even things we haven't thought of yet. Maybe we could say something like: It MUST NOT change over time, even if the parent feed or entry element is relocated, migrated, syndicated, republished, exported, imported or otherwise changed, copied or moved. > Overall, I personally think the current The Atom Syndication Format is > lacking in examples. I agree. > Clearly, this is an area where there is signficant confusion. Definately. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 25 16:31:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17435 for ; Wed, 25 Aug 2004 16:31:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKMkMI003802; Wed, 25 Aug 2004 13:22:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKMkqw003801; Wed, 25 Aug 2004 13:22:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PKMi3t003789 for ; Wed, 25 Aug 2004 13:22:45 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 21350 invoked by uid 65534); 25 Aug 2004 20:22:43 -0000 Received: from pD9FF074F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.7.79) by mail.gmx.net (mp016) with SMTP; 25 Aug 2004 22:22:43 +0200 X-Authenticated: #1915285 Message-ID: <412CF511.9050007@gmx.de> Date: Wed, 25 Aug 2004 22:22:41 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Tue, 24 Aug 2004 08:15:41 +0200, Julian Reschke > wrote: > >>> That's a good reason for requiring publishers to do the >>> canonicalization and normalization (c14n11n :) and allowing >>> consumers to compare atom:id char-by-char (as strings, not as URI's). >> >> >> No, that's a good reason to require just char-by-char comparison. > > > So the Atom spec shouldn't say anything about either normalization or > canonicalization as something publishers SHOULD or MUST do with their > atom:id URI's? Yes. Just state that they are plain strings using URI syntax (absoluteURI production in RFC2396) and that they are to be compared character-by-character. This is all that's needed for the desired syntax, and as far as I can tell, it's the simplest way to achieve it. I'm not against canonicalization; but if the spec mentions it there should be a clear benefit in doing it. Saying "the IDs will work better when recipients break the spec when comparing them" IMHO is the wrong approach to spec writing. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Aug 25 16:36:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17688 for ; Wed, 25 Aug 2004 16:36:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKNfUX003862; Wed, 25 Aug 2004 13:23:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKNfFF003861; Wed, 25 Aug 2004 13:23:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PKNdaG003850 for ; Wed, 25 Aug 2004 13:23:40 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 2176 invoked by uid 65534); 25 Aug 2004 20:23:38 -0000 Received: from pD9FF074F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.7.79) by mail.gmx.net (mp026) with SMTP; 25 Aug 2004 22:23:38 +0200 X-Authenticated: #1915285 Message-ID: <412CF547.5020704@gmx.de> Date: Wed, 25 Aug 2004 22:23:35 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Anne van Kesteren , Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Fri, 20 Aug 2004 09:52:19 +0200, Anne van Kesteren > wrote: > >> I don't see why we have to treat URIs as strings. Normalizing them as >> Mark Pilgrim explained[1] seems like a more sensible and correct >> thing to do. > > > I agree, but only if that burden can be put on the publisher. Consumers > should be able to just do string comparison. If consumers compare them as strings anyway, there's no point in requiring canonicalization, right? -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Aug 25 16:39:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17913 for ; Wed, 25 Aug 2004 16:39:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKTjtn004473; Wed, 25 Aug 2004 13:29:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKTjQT004468; Wed, 25 Aug 2004 13:29:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKTiSk004404; Wed, 25 Aug 2004 13:29:44 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id A00024F0F6; Wed, 25 Aug 2004 16:29:48 -0400 (EDT) Date: Wed, 25 Aug 2004 16:29:48 -0400 From: Dan Brickley To: Dare Obasanjo Cc: Danny Ayers , Paul Hoffman / IMC , Atom WG Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] Message-ID: <20040825202948.GM20056@homer.w3.org> References: <20040825170522.GL20056@homer.w3.org> <20040825173458.24427.qmail@web41214.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040825173458.24427.qmail@web41214.mail.yahoo.com> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Dare Obasanjo [2004-08-25 10:34-0700] > > --- Dan Brickley wrote: > > > > Regarding > > concrete proposals, I proposed that the > > http://nature.com/rss/ Jobs use > > case be taken on board by this WG as 'something we > > could try to make > > sure was do-able in Atom'. I guess I should go read > > up on the proper > > process for articulating that request. > > I don't see a use case articulated at the end of that > link just links to a bunch of RSS 1.0 feeds with some > extension elements from the Nature Jobs namespace. > > To articulate a use case I'd expect to hear what > information the producer would like put in the feed > and what is expected for consumers to do with that > information. OK I'll talk with the Nature folks and try to flesh this out. > > BTW I hope my contributions last week made clear > > that I'm not in the (empty > > AFAIK) 'RDF will solve all problems' camp. It's just > > the only way I know > > of to do decentralised, loosly coordinated and > > fine-grained namespace mixing. > > I'm very open to their being other ways to do this > > in XML, I just haven't > > encountered any yet. > > Sounds like a contradiction. How can you claim to be > open minded if you've already decided that 'RDF is the > only way'? (through gritted teeth) I said it's the only way *that I know of*. (Right their, in the last sentence you read before responding. 7 lines up.) For better or worse, XML schema languages do tend to be more granular than the RDF approach; they typically define document types or element/attribute patterns that give us re-usable chunks of document. RDF is the only deployed approach *that* *I'm* *familiar* *with* where namespaces are typically mixed right in with each other in a well defined way. But I'm open to suprises; until I found http://www.itiran.com/?type=xml I thought everyone put dates in their feeds, for example. I most certainly don't think RDF is the only way to do this stuff. But I do know that design by committee is a major risk in standards work, and that known approaches are preferable to newly invented ones. Which is why I'm cautious about Atom chewing up bandwidth and brains reinventing a wheel. > Also I'm not sure what is meant here by namespace > mixing. Mixing the syntax of two XML vocabularies can > be done with strcat() in C. However I'm sure that's > not what you mean. So what do you mean? I mean having an architecture that offers guidance to the creators of those namespaces such that their products can be deployed directly alongside other namespaces without them having to have pairwise agreements about whose elements can go inside whose. Not as sibling elements each with their own subtree, but mixed right in with each other, elements inside each other's, attributes on each other's elements. Dan From owner-atom-syntax@mail.imc.org Wed Aug 25 16:39:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17940 for ; Wed, 25 Aug 2004 16:39:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKTUN3004230; Wed, 25 Aug 2004 13:29:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKTUYi004229; Wed, 25 Aug 2004 13:29:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKTS9Y004221 for ; Wed, 25 Aug 2004 13:29:30 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 9407C7C2EB; Wed, 25 Aug 2004 23:20:18 +0200 (CEST) Date: Wed, 25 Aug 2004 22:32:05 +0200 To: "Mark Nottingham" Subject: Re: PaceIdConstruct Cc: Atom-Syntax , "Sam Ruby" References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <1931C8B0-F285-11D8-B175-000A95BD86C0@mnot.net> <476b71e80408200239506dc643@mail.gmail.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 20 Aug 2004 09:34:38 -0700, Mark Nottingham wrote: > E.g., "stored along with the resource" -- what does that mean, precisely? Good question, since the resource can be stored on whatever storage unit you'd like; from simple file systems to revisioned and high-tech content management systems RDBMS's. > Am I conformant if the ID is in the same database? I would say it needs to be stored in the same database row as the entry (if the entry is the «resource»). We could probably enumerate a couple of storage alternatives to get this clarified. What about adding the following text: If the resource is stored in a database, there should be a column representing atom:id that contains the full atom:id URI string. If the resource is stored in an XML file in the file system, there should be an XML element (or attribute) representing atom:id that contains the full atom:id URI string. The wording here is a bit curved, but something along those lines would probably make it clearer what we want, no? > WRT "dynamic," is this requirement violated if I can examine a resource > and derive the ID from its data? Metadata? Not if you only do it once. If you do it each time the resource is requested, you're violating the requirement. Maybe «dymanic» isn't the best word here. Something about «first time creation» should probably get into the text somehow. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Aug 25 16:39:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17961 for ; Wed, 25 Aug 2004 16:39:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PKVUUc004782; Wed, 25 Aug 2004 13:31:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PKVU2s004781; Wed, 25 Aug 2004 13:31:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PKVTxk004752 for ; Wed, 25 Aug 2004 13:31:29 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 13160 invoked by uid 65534); 25 Aug 2004 20:31:28 -0000 Received: from pD9FF074F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.7.79) by mail.gmx.net (mp003) with SMTP; 25 Aug 2004 22:31:28 +0200 X-Authenticated: #1915285 Message-ID: <412CF71E.4000103@gmx.de> Date: Wed, 25 Aug 2004 22:31:26 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> In-Reply-To: <412CF511.9050007@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > character-by-character. This is all that's needed for the desired > syntax, and as far as I can tell, it's the simplest way to achieve it. Sorry: s/syntax/semantics/ Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Aug 25 17:27:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23971 for ; Wed, 25 Aug 2004 17:26:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PLErAd007321; Wed, 25 Aug 2004 14:14:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PLErKQ007320; Wed, 25 Aug 2004 14:14:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PLEp2b007311 for ; Wed, 25 Aug 2004 14:14:51 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so145149rnk for ; Wed, 25 Aug 2004 14:14:48 -0700 (PDT) Received: by 10.38.72.72 with SMTP id u72mr2144500rna; Wed, 25 Aug 2004 14:14:47 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Wed, 25 Aug 2004 14:14:47 -0700 (PDT) Message-ID: <14be96d30408251414192f892a@mail.gmail.com> Date: Wed, 25 Aug 2004 17:14:47 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Julian Reschke Subject: Re: PaceIdConstruct Cc: "Asbjørn Ulsberg" , Anne van Kesteren , Atom-Syntax In-Reply-To: <412CF547.5020704@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke wrote: > If consumers compare them as strings anyway, there's no point in > requiring canonicalization, right? Some consumers will undoubtedly compare them as strings, since (I believe) all consumers currently compare RSS's as strings. These consumers are wrong (but only sometimes, because is only sometimes a URI), because comparing URIs is surprisingly difficult. Some consumers will undoubtedly use their programming platform's fancy URI class or equivalent, like this: http://intertwingly.net/blog/2004/07/31/URI-Equivalence We would like both of these classes of consumers to come up with the same answer in all cases as to whether two atom:ids are the same. I believe that requiring canonical URIs for atom:id achieves that. I believe that no other solution achieves that without at least one part of the process being counterintuitive and/or difficult for consumers. You could... 1. Tell consumers who don't have fancy URI classes that they need to perform a 10-step normalization process (which I detailed in my article) to compare values WHOSE ONLY PURPOSE IN LIFE IS TO BE COMPARED. This is counterintuitive and difficult. 2. Tell consumers who have fancy URI classes that they can't use them, despite clear language in the spec that atom:id MUST be a URI, and despite the consumer being able to use their fancy URI class to do other things with every other URI in Atom. This is counterintuitive. This is part of the "principle of least surprise" I was talking about in my article. 3. Tell consumers that they can compare atom:ids any way they like, but they may come up with different answers about whether two atom:ids are the same or different, and that that's somehow OK. This is counterintuitive and simply wrong (despite being advocated by our working group chair). I have made this case repeatedly, on-list and off: if client A can make a reasonable case that two atom:ids are the same, and client B can make a reasonable case that those two atom:ids are different, then we have failed, and we may as well just pack it up and go home. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed Aug 25 17:30:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24298 for ; Wed, 25 Aug 2004 17:30:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PLKZTY007638; Wed, 25 Aug 2004 14:20:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PLKZvc007637; Wed, 25 Aug 2004 14:20:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PLKZoc007631 for ; Wed, 25 Aug 2004 14:20:35 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 57580 invoked by uid 17064); 25 Aug 2004 21:20:38 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.136.80]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Aug 2004 21:20:38 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom Syntax From: Henry Story Subject: URIs vs Strings Date: Wed, 25 Aug 2004 23:20:32 +0200 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There is a debate going on on whether to use URI's or strings for ids. As I understand IDs have to be globally unique. So my question is: How can a blog writer find a globally unique string to identify his entry with? I think he absolutely cannot. Any string you find could have been found by someone else. In order to be able to make sure that a string is globally unique it has to be constructed according to rules that will guarantee uniqueness. And this means that only URI's (or URNs) can be used. There has to be a well defined construction mechanism. Is there anything I am missing in that argument? Henry http://bblfish.net From owner-atom-syntax@mail.imc.org Wed Aug 25 17:36:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25029 for ; Wed, 25 Aug 2004 17:36:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PLSkG2008113; Wed, 25 Aug 2004 14:28:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PLSkhw008112; Wed, 25 Aug 2004 14:28:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PLSkMn008102 for ; Wed, 25 Aug 2004 14:28:46 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so266250rnk for ; Wed, 25 Aug 2004 14:28:45 -0700 (PDT) Received: by 10.38.102.54 with SMTP id z54mr1881627rnb; Wed, 25 Aug 2004 14:28:45 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Wed, 25 Aug 2004 14:28:45 -0700 (PDT) Message-ID: <14be96d3040825142839283d2c@mail.gmail.com> Date: Wed, 25 Aug 2004 17:28:45 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Julian Reschke Subject: Re: ID wording Cc: "Asbjørn Ulsberg" , Atom-Syntax In-Reply-To: <412CF511.9050007@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 22:22:41 +0200, Julian Reschke wrote: > Yes. Just state that they are plain strings using URI syntax > (absoluteURI production in RFC2396) and that they are to be compared > character-by-character. What you are advocating is what I listed as alternate solution #2 in my recent message: "atom:id MUST be a URI, except you can't use your URI class to compare it... oh, and you can't do anything else with atom:ids except compare them." This is counterintuitive. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed Aug 25 18:27:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02193 for ; Wed, 25 Aug 2004 18:27:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PM9MYA011488; Wed, 25 Aug 2004 15:09:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PM9MZW011487; Wed, 25 Aug 2004 15:09:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PM9MKf011476 for ; Wed, 25 Aug 2004 15:09:22 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc12) with SMTP id <20040825220922014007o8vfe>; Wed, 25 Aug 2004 22:09:22 +0000 Date: Wed, 25 Aug 2004 16:09:21 -0600 Subject: Re: PaceIdConstruct Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <14be96d30408251414192f892a@mail.gmail.com> Message-Id: <6AAAFCC9-F6E3-11D8-AFC5-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, August 25, 2004, at 03:14 PM, Mark Pilgrim wrote: > 2. Tell consumers who have fancy URI classes that they can't use them, > despite clear language in the spec that atom:id MUST be a URI, and > despite the consumer being able to use their fancy URI class to do > other things with every other URI in Atom. This is counterintuitive. > This is part of the "principle of least surprise" I was talking about > in my article. > Assuming we specify that ID's must be character-by-character comparable, we obviously won't have a problem with false negatives no matter what (non-ridiculous) method is used to compare, because even if that method mangles the IDs in unintended ways, it will mangle both sides of the comparison identically. The issue is false positives, where two different IDs become the same after having been mangled. Is this non-trivially more likely to occur than two people actually generating character-for-character identical IDs? If my ID is http://www.geckotribe.com/blog/2004/8/25/1, it's clearly not going to get confused with someone else's http://www.foo.net:80/blog/2004/8/25/1 whether compared character by character or by any other method. On the other hand, if one person is using the ID http://www.bloghost.com/2004/8/25/1 for their ID, and someone else is using http://www.bloghost.com:80/2004/8/25/1, then something is fundamentally wrong with the way they're generating their IDs. They should be doing something like http://www.bloghost.com/blog-a/2004/8/25/1 and http://www.bloghost.com:80/blog-b/2004/8/25/1 anyway. From owner-atom-syntax@mail.imc.org Wed Aug 25 18:28:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02251 for ; Wed, 25 Aug 2004 18:28:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMFsB6011841; Wed, 25 Aug 2004 15:15:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMFs2D011840; Wed, 25 Aug 2004 15:15:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PMFrK8011825 for ; Wed, 25 Aug 2004 15:15:53 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 25463 invoked by uid 65534); 25 Aug 2004 22:15:52 -0000 Received: from pD9FF074F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.7.79) by mail.gmx.net (mp027) with SMTP; 26 Aug 2004 00:15:52 +0200 X-Authenticated: #1915285 Message-ID: <412D0F95.8030502@gmx.de> Date: Thu, 26 Aug 2004 00:15:49 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Anne van Kesteren , Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <14be96d30408251414192f892a@mail.gmail.com> In-Reply-To: <14be96d30408251414192f892a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke > wrote: > >>If consumers compare them as strings anyway, there's no point in >>requiring canonicalization, right? > > > Some consumers will undoubtedly compare them as strings, since (I > believe) all consumers currently compare RSS's as strings. > These consumers are wrong (but only sometimes, because is only > sometimes a URI), because comparing URIs is surprisingly difficult. > > Some consumers will undoubtedly use their programming platform's fancy > URI class or equivalent, like this: > > http://intertwingly.net/blog/2004/07/31/URI-Equivalence > > We would like both of these classes of consumers to come up with the > same answer in all cases as to whether two atom:ids are the same. I > believe that requiring canonical URIs for atom:id achieves that. I > believe that no other solution achieves that without at least one part > of the process being counterintuitive and/or difficult for consumers. > > You could... > > 1. Tell consumers who don't have fancy URI classes that they need to > perform a 10-step normalization process (which I detailed in my > article) to compare values WHOSE ONLY PURPOSE IN LIFE IS TO BE > COMPARED. This is counterintuitive and difficult. Yes. > 2. Tell consumers who have fancy URI classes that they can't use them, > despite clear language in the spec that atom:id MUST be a URI, and > despite the consumer being able to use their fancy URI class to do > other things with every other URI in Atom. This is counterintuitive. > This is part of the "principle of least surprise" I was talking about > in my article. Well, if the spec tells them that the ID is a *string* that has URI syntax, and that it needs to be compared as a string, I don't see a problem. As a matter of fact, this has *provably* worked for XML namespaces (show me one XML+NS processor that gets this wrong!), so why shouldn't it work for something else? > 3. Tell consumers that they can compare atom:ids any way they like, > but they may come up with different answers about whether two atom:ids > are the same or different, and that that's somehow OK. This is > counterintuitive and simply wrong (despite being advocated by our > working group chair). I have made this case repeatedly, on-list and > off: if client A can make a reasonable case that two atom:ids are the > same, and client B can make a reasonable case that those two atom:ids > are different, then we have failed, and we may as well just pack it up > and go home. No objection. Just stick with char-by-char comparison, and the spec will be as simple as possible, and there'll no way comparison results can vary. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Aug 25 18:29:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02331 for ; Wed, 25 Aug 2004 18:29:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMHcCp011930; Wed, 25 Aug 2004 15:17:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMHcY6011929; Wed, 25 Aug 2004 15:17:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PMHaZG011919 for ; Wed, 25 Aug 2004 15:17:37 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 5034 invoked by uid 65534); 25 Aug 2004 22:17:36 -0000 Received: from pD9FF074F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.7.79) by mail.gmx.net (mp020) with SMTP; 26 Aug 2004 00:17:36 +0200 X-Authenticated: #1915285 Message-ID: <412D0FFD.4050908@gmx.de> Date: Thu, 26 Aug 2004 00:17:33 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <14be96d3040825142839283d2c@mail.gmail.com> In-Reply-To: <14be96d3040825142839283d2c@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > On Wed, 25 Aug 2004 22:22:41 +0200, Julian Reschke > wrote: > >>Yes. Just state that they are plain strings using URI syntax >>(absoluteURI production in RFC2396) and that they are to be compared >>character-by-character. > > > What you are advocating is what I listed as alternate solution #2 in > my recent message: "atom:id MUST be a URI, except you can't use your > URI class to compare it... oh, and you can't do anything else with > atom:ids except compare them." This is counterintuitive. But that's the whole point of ids, right? What else except comparing for equality (or using them as a key, or doing other id-ish things...) do you want to do with them? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Aug 25 18:37:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03548 for ; Wed, 25 Aug 2004 18:37:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMR45L012416; Wed, 25 Aug 2004 15:27:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMR4ve012415; Wed, 25 Aug 2004 15:27:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PMR4CJ012401 for ; Wed, 25 Aug 2004 15:27:04 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825222702.89095.qmail@web41214.mail.yahoo.com> Received: from [24.18.130.238] by web41214.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 15:27:02 PDT Date: Wed, 25 Aug 2004 15:27:02 -0700 (PDT) From: Dare Obasanjo Subject: Re: URIs vs Strings To: Henry Story , Atom Syntax In-Reply-To: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Henry Story wrote: > > How can a blog writer find a globally unique string > to identify his > entry with? > > I think he absolutely cannot. Any string you find > could have been found > by someone else. In order to be able to make sure > that a string is > globally unique it has to be constructed according > to rules that will > guarantee uniqueness. And this means that only URI's > (or URNs) can be > used. There has to be a well defined construction > mechanism. Incorrect. Google for "DEC AND UUID" or "Microsoft AND GUID". URIs provide a 'cheap' and 'easy' mechanism for coming up with globally unique identifiers. They are NOT the only way. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Aug 25 18:43:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03883 for ; Wed, 25 Aug 2004 18:43:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMTngN012720; Wed, 25 Aug 2004 15:29:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMTnEu012719; Wed, 25 Aug 2004 15:29:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41211.mail.yahoo.com (web41211.mail.yahoo.com [66.218.93.44]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PMTmxZ012711 for ; Wed, 25 Aug 2004 15:29:48 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040825222948.29877.qmail@web41211.mail.yahoo.com> Received: from [24.18.130.238] by web41211.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 15:29:48 PDT Date: Wed, 25 Aug 2004 15:29:48 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID wording To: Mark Pilgrim , Julian Reschke Cc: "Asbjørn" Ulsberg , Atom-Syntax In-Reply-To: <14be96d3040825142839283d2c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Mark Pilgrim wrote: > > What you are advocating is what I listed as > alternate solution #2 in > my recent message: "atom:id MUST be a URI, except > you can't use your > URI class to compare it... oh, and you can't do > anything else with > atom:ids except compare them." This is > counterintuitive. This is exactly how XML namespaces work. Are you suggesting that what the W3C Namespaces in XML recommendation specifies is wrong?[0] [0] There is no right answer to this question. :) ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Wed Aug 25 18:46:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04018 for ; Wed, 25 Aug 2004 18:46:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMadDO013144; Wed, 25 Aug 2004 15:36:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMadT5013143; Wed, 25 Aug 2004 15:36:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMadVn013137 for ; Wed, 25 Aug 2004 15:36:39 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 22386 invoked by uid 17064); 25 Aug 2004 22:36:44 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.136.80]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Aug 2004 22:36:44 -0000 In-Reply-To: <20040825222702.89095.qmail@web41214.mail.yahoo.com> References: <20040825222702.89095.qmail@web41214.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3B11DBBF-F6E7-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Dare Obasanjo From: Henry Story Subject: Re: URIs vs Strings Date: Thu, 26 Aug 2004 00:36:39 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Aug 2004, at 00:27, Dare Obasanjo wrote: > > --- Henry Story wrote: > >> >> How can a blog writer find a globally unique string >> to identify his >> entry with? >> >> I think he absolutely cannot. Any string you find >> could have been found >> by someone else. In order to be able to make sure >> that a string is >> globally unique it has to be constructed according >> to rules that will >> guarantee uniqueness. And this means that only URI's >> (or URNs) can be >> used. There has to be a well defined construction >> mechanism. > > Incorrect. Google for "DEC AND UUID" or "Microsoft AND > GUID". URIs provide a 'cheap' and 'easy' mechanism for > coming up with globally unique identifiers. They are > NOT the only way. You are correct. I need to restate my position. If one wants to be able to create a globally (universally?) unique ID in a distributed manner [1] one needs to have rules to allow the construction of such an ID. A String is by definition just a sequence of bytes. Two strings are identical if the sequence is identical. It has no structure apart from that. It certainly has no structure that says anything about creating a globally unique string. So whatever an ID is it *cannot* be a String. Henry [1] thanks to Julian Reschke for this phrasing. From owner-atom-syntax@mail.imc.org Wed Aug 25 18:51:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04277 for ; Wed, 25 Aug 2004 18:51:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMi65a013647; Wed, 25 Aug 2004 15:44:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMi6Oi013646; Wed, 25 Aug 2004 15:44:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMi5iB013635 for ; Wed, 25 Aug 2004 15:44:05 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so148843rnk for ; Wed, 25 Aug 2004 15:44:05 -0700 (PDT) Received: by 10.38.72.72 with SMTP id u72mr2177382rna; Wed, 25 Aug 2004 15:44:05 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Wed, 25 Aug 2004 15:44:05 -0700 (PDT) Message-ID: <14be96d304082515441a82a0f9@mail.gmail.com> Date: Wed, 25 Aug 2004 18:44:05 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Julian Reschke Subject: Re: ID wording Cc: "Asbjørn Ulsberg" , Atom-Syntax In-Reply-To: <412D0FFD.4050908@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <14be96d3040825142839283d2c@mail.gmail.com> <412D0FFD.4050908@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 00:17:33 +0200, Julian Reschke wrote: > Mark Pilgrim wrote: > > On Wed, 25 Aug 2004 22:22:41 +0200, Julian Reschke > > wrote: > >>Yes. Just state that they are plain strings using URI syntax > >>(absoluteURI production in RFC2396) and that they are to be compared > >>character-by-character. > > > > What you are advocating is what I listed as alternate solution #2 in > > my recent message: "atom:id MUST be a URI, except you can't use your > > URI class to compare it... oh, and you can't do anything else with > > atom:ids except compare them." This is counterintuitive. > > But that's the whole point of ids, right? What else except comparing for > equality (or using them as a key, or doing other id-ish things...) do > you want to do with them? I don't know how many ways I can repeat myself, so I give up. Let's do it Julian's way, and then spend the next ten years explaining to people that using their platform's URI classes to compare URIs is subtlely wrong. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed Aug 25 18:58:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04989 for ; Wed, 25 Aug 2004 18:58:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMqAin014151; Wed, 25 Aug 2004 15:52:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMqAr7014150; Wed, 25 Aug 2004 15:52:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMq8qk014079 for ; Wed, 25 Aug 2004 15:52:09 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 26 Aug 2004 08:58:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 26 Aug 2004 08:51:28 +1000 Subject: Re: Chair's attention requested: [was Can atom be Del.icio.us? Or, can Del.icio.us be atomic?] From: Eric Scheid To: Dare Obasanjo , Sam Ruby CC: Atom Syntax Message-ID: In-Reply-To: <20040825172143.21590.qmail@web41214.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26/8/04 3:21 AM, "Dare Obasanjo" wrote: >> At the moment, the Atom link element is modelled after the HTML link tag[3], >> which has a number of advantages[4]. >> > Yes, if all the links have similar semantics. Specifically what comes to mind > is if as a fallback they can all be rendered as human clickable links. In > fact, that simple guideline is probably all that is really needed in the Atom > case. Although it will mean that for consistency that Atom shouldn't use > atom:link for the various service URIs which doesn't seem like a bad tradeoff > to me. > +1 From owner-atom-syntax@mail.imc.org Wed Aug 25 19:01:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05256 for ; Wed, 25 Aug 2004 19:01:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMqTES015008; Wed, 25 Aug 2004 15:52:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMqSJQ014985; Wed, 25 Aug 2004 15:52:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMqRCZ014887 for ; Wed, 25 Aug 2004 15:52:27 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[127.0.0.1]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C06cz-0002m2-O6; Wed, 25 Aug 2004 22:52:25 +0000 Message-ID: <412D1834.80108@franklinmint.fm> Date: Wed, 25 Aug 2004 18:52:36 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Henry Story , Atom Syntax Subject: make it stop (was: URIs vs Strings) References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> In-Reply-To: <412D10B0.1010008@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Henry Story wrote: > >> Is there anything I am missing in that argument? > > > No, that's correct. ... > URIs are the most > popular, flexible and and widely accepted way to achieve that goal. It's also the agreed upon consensus[0], So there's really no debate here. The only open question is spec text about these URIs, but note that the current issues list[1] hasn't scheduled this question. IMHO, this debate on this issue will be more productive after a new draft of the format spec is issued. Currently scheduled: PaceDigitalSignatures PaceErrVerb PaceEquivalents PaceItemLicense PaceReduceMustMay PaceServiceError PaceSimplifiedFeedFormat Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg08572.html [1] http://www.imc.org/atom-syntax/mail-archive/msg08792.html From owner-atom-syntax@mail.imc.org Wed Aug 25 19:03:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05422 for ; Wed, 25 Aug 2004 19:03:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMuGav016939; Wed, 25 Aug 2004 15:56:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMuF9Q016938; Wed, 25 Aug 2004 15:56:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMuDDT016918 for ; Wed, 25 Aug 2004 15:56:14 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 26 Aug 2004 09:03:12 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 26 Aug 2004 08:55:58 +1000 Subject: Re: Link requirements [was : Can atom be Del.icio.us?] From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <412CD8BF.5060403@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26/8/04 4:21 AM, "Sam Ruby" wrote: > (1) Each atom:entry element must have one or more link elements > associated with it. -0 > (10) Linking to service interfaces is a valid use case for this element -1 From owner-atom-syntax@mail.imc.org Wed Aug 25 19:10:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05859 for ; Wed, 25 Aug 2004 19:10:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PN2dON018053; Wed, 25 Aug 2004 16:02:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PN2djD018052; Wed, 25 Aug 2004 16:02:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PN2Xji018043 for ; Wed, 25 Aug 2004 16:02:35 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 26 Aug 2004 09:09:17 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 26 Aug 2004 09:02:05 +1000 Subject: Re: ID wording From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <14be96d3040825142839283d2c@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26/8/04 7:28 AM, "Mark Pilgrim" wrote: > wrote: >> Yes. Just state that they are plain strings using URI syntax >> (absoluteURI production in RFC2396) and that they are to be compared >> character-by-character. > > What you are advocating is what I listed as alternate solution #2 in > my recent message: "atom:id MUST be a URI, except you can't use your > URI class to compare it... oh, and you can't do anything else with > atom:ids except compare them." This is counterintuitive. No, he said they are *strings* that look[1] like URIs, not URIs that are to be treated as strings. Different thing entirely. e. [1] "look like" = shorthand for "has special rules as to composition, rules which just so happen to be the same as those for URI serialisation" From owner-atom-syntax@mail.imc.org Wed Aug 25 19:11:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05908 for ; Wed, 25 Aug 2004 19:11:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PN4cQN018191; Wed, 25 Aug 2004 16:04:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PN4cFk018190; Wed, 25 Aug 2004 16:04:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PN4cXi018184 for ; Wed, 25 Aug 2004 16:04:38 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 48085 invoked by uid 17064); 25 Aug 2004 23:04:43 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.136.80]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Aug 2004 23:04:43 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <412D1834.80108@franklinmint.fm> References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <412D1834.80108@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23B2AF94-F6EB-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: make it stop (was: URIs vs Strings) Date: Thu, 26 Aug 2004 01:04:38 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Aug 2004, at 00:52, Robert Sayre wrote: > > Julian Reschke wrote: >> Henry Story wrote: >>> Is there anything I am missing in that argument? >> No, that's correct. > ... >> URIs are the most popular, flexible and and widely accepted way to >> achieve that goal. > > It's also the agreed upon consensus[0], So there's really no debate > here. The only Ok. I understand now. Thanks. Henry [snip] > at > > Robert Sayre > > [0] http://www.imc.org/atom-syntax/mail-archive/msg08572.html > [1] http://www.imc.org/atom-syntax/mail-archive/msg08792.html > From owner-atom-syntax@mail.imc.org Wed Aug 25 19:11:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05940 for ; Wed, 25 Aug 2004 19:11:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PN5DU4018231; Wed, 25 Aug 2004 16:05:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PN5DrJ018230; Wed, 25 Aug 2004 16:05:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PN5Cjb018224 for ; Wed, 25 Aug 2004 16:05:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail15.mac.com (webmail15-en1 [10.13.10.141]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7PN5HJd002518; Wed, 25 Aug 2004 16:05:17 -0700 (PDT) Received: from webmail15 (localhost [127.0.0.1]) by webmail15.mac.com (8.12.6/8.12.2) with ESMTP id i7PN5HaK010304; Wed, 25 Aug 2004 16:05:17 -0700 (PDT) Message-ID: <12980955.1093475117092.JavaMail.dtcd@mac.com> Date: Wed, 25 Aug 2004 19:05:17 -0400 From: Graham Parks To: Mark Pilgrim Subject: Re: ID wording Cc: Atom-Syntax in-reply-to: <14be96d304082515441a82a0f9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <14be96d3040825142839283d2c@mail.gmail.com> <412D0FFD.4050908@gmx.de> <14be96d304082515441a82a0f9@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, August 25, 2004, at 06:51PM, Mark Pilgrim wrote: >I don't know how many ways I can repeat myself, so I give up. Let's >do it Julian's way, and then spend the next ten years explaining to >people that using their platform's URI classes to compare URIs is >subtlely wrong. The problem is that there's more than one way to compare URIs, and not all URI classes do the same thing. For consistency's sake we need to specify one method, and we're specifying the simplest. Canonicalization has been suggested as an alternative solution (right?). I see how that would work, but I much prefer the simplicity of the above solution. It is just a matter of personal preference, because from a technical standpoint either system can just as easily be messed up by a single broken implementation. Graham From owner-atom-syntax@mail.imc.org Wed Aug 25 19:19:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02361 for ; Wed, 25 Aug 2004 18:30:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PMKagF012085; Wed, 25 Aug 2004 15:20:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PMKaLc012084; Wed, 25 Aug 2004 15:20:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7PMKYnw012074 for ; Wed, 25 Aug 2004 15:20:35 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 18493 invoked by uid 65534); 25 Aug 2004 22:20:34 -0000 Received: from pD9FF074F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.7.79) by mail.gmx.net (mp021) with SMTP; 26 Aug 2004 00:20:34 +0200 X-Authenticated: #1915285 Message-ID: <412D10B0.1010008@gmx.de> Date: Thu, 26 Aug 2004 00:20:32 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Atom Syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> In-Reply-To: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > There is a debate going on on whether to use URI's or strings for ids. > As I understand IDs have to be globally unique. So my question is: > > How can a blog writer find a globally unique string to identify his > entry with? > > I think he absolutely cannot. Any string you find could have been found > by someone else. In order to be able to make sure that a string is > globally unique it has to be constructed according to rules that will > guarantee uniqueness. And this means that only URI's (or URNs) can be > used. There has to be a well defined construction mechanism. > > Is there anything I am missing in that argument? No, that's correct. You may be able to substitute "URI" by another globally controlled scheme to create new IDs in a distributed manner (like phone numbers + private extensions), but I guess URIs are the most popular, flexible and and widely accepted way to achieve that goal. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Aug 25 19:55:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08381 for ; Wed, 25 Aug 2004 19:55:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PNkP6e022696; Wed, 25 Aug 2004 16:46:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PNkPgq022695; Wed, 25 Aug 2004 16:46:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PNkOZx022688 for ; Wed, 25 Aug 2004 16:46:24 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 62F0C4F257; Wed, 25 Aug 2004 19:46:27 -0400 (EDT) Message-Id: <4.2.0.58.J.20040826082340.05b71bf0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 26 Aug 2004 08:27:53 +0900 To: Mark Pilgrim , Julian Reschke From: Martin Duerst Subject: Re: ID wording Cc: =?ISO-2022-JP?B?IkFzYmobJEJ4chsoQm4gVWxzYmVyZyI=?= , Atom-Syntax In-Reply-To: <14be96d3040825142839283d2c@mail.gmail.com> References: <412CF511.9050007@gmx.de> <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 17:28 04/08/25 -0400, Mark Pilgrim wrote: >What you are advocating is what I listed as alternate solution #2 in >my recent message: "atom:id MUST be a URI, except you can't use your >URI class to compare it... oh, and you can't do anything else with >atom:ids except compare them." This is counterintuitive. It may sound counterintuitive, but the 'I' in 'URI' stands for 'Identifier'. For identifiers, comparision for equality is the only thing that really counts. It answers the question: Is this the one that I mean. What else would you want to do with the URI in atom:id? [Occasionally, you will be able to dereference it, but in general, that won't work.] Regards, Martin. From owner-atom-syntax@mail.imc.org Wed Aug 25 21:08:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12594 for ; Wed, 25 Aug 2004 21:08:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q0wTho027406; Wed, 25 Aug 2004 17:58:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q0wT8C027405; Wed, 25 Aug 2004 17:58:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q0wRS2027399 for ; Wed, 25 Aug 2004 17:58:28 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so153129rnk for ; Wed, 25 Aug 2004 17:58:33 -0700 (PDT) Received: by 10.38.72.72 with SMTP id u72mr2221554rna; Wed, 25 Aug 2004 17:58:33 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Wed, 25 Aug 2004 17:58:33 -0700 (PDT) Message-ID: <14be96d304082517583044d3ff@mail.gmail.com> Date: Wed, 25 Aug 2004 20:58:33 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Martin Duerst Subject: Re: ID wording Cc: Julian Reschke , asbjorn@tigerstaden.no, Atom-Syntax In-Reply-To: <4.2.0.58.J.20040826082340.05b71bf0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <412CF511.9050007@gmx.de> <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <4.2.0.58.J.20040826082340.05b71bf0@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 08:27:53 +0900, Martin Duerst wrote: > At 17:28 04/08/25 -0400, Mark Pilgrim wrote: > > >What you are advocating is what I listed as alternate solution #2 in > >my recent message: "atom:id MUST be a URI, except you can't use your > >URI class to compare it... oh, and you can't do anything else with > >atom:ids except compare them." This is counterintuitive. > > It may sound counterintuitive, but the 'I' in 'URI' stands for > 'Identifier'. For identifiers, comparision for equality is the > only thing that really counts. It answers the question: Is this > the one that I mean. I understand that their only purpose is comparison. The counterintuitive part is that they look exactly like URIs, but you can't use your programming language's URI class to compare them. http://intertwingly.net/blog/2004/07/31/URI-Equivalence I guess Julian doesn't use languages like Java and C#, but I hear they're catching on. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed Aug 25 21:45:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14267 for ; Wed, 25 Aug 2004 21:45:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q1aCi6029784; Wed, 25 Aug 2004 18:36:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q1aC3Q029783; Wed, 25 Aug 2004 18:36:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q1aCQb029777 for ; Wed, 25 Aug 2004 18:36:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7Q1aHtR010368; Wed, 25 Aug 2004 18:36:17 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i7Q1aGh3007893; Wed, 25 Aug 2004 18:36:16 -0700 (PDT) In-Reply-To: <14be96d304082517583044d3ff@mail.gmail.com> References: <412CF511.9050007@gmx.de> <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <4.2.0.58.J.20040826082340.05b71bf0@localhost> <14be96d304082517583044d3ff@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--787137386; protocol="application/pkcs7-signature" Message-Id: <5466C310-F700-11D8-8440-000A95DC3D90@mac.com> Cc: Atom-Syntax From: Graham Subject: Re: ID wording Date: Wed, 25 Aug 2004 18:36:18 -0700 To: Mark Pilgrim X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-1--787137386 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Aug 2004, at 5:58 pm, Mark Pilgrim wrote: > I understand that their only purpose is comparison. The > counterintuitive part is that they look exactly like URIs, but you > can't use your programming language's URI class to compare them. But it's equally conterintuitive that they're defined as URI but I can't put a whole gamut of URIs in them because they don't fit a bunch of arbitrary rules I don't have time to learn. You can't win. Graham --Apple-Mail-1--787137386 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI2MDEzNjE5WjAjBgkqhkiG9w0BCQQxFgQUNuc2S6BQNnyJ0nMRRaHKuEDL RYQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAnlXSu57tFaOxij8OAL8uSsJz xJ6ogKgFYF/S2z7APt8yQGVAQs+8AuAszG9eS8fLYop9wxrse4z+Tbbx+MZpPdP1Hu5WeEgG5qxs TLYAypAgsZxqMxSLDaRjCZdc5pzHqyzMWUqvZkd16p6LOX1WnDaNgbwfN+Tk3P+ZVJED/Y1ICS1N 1fFu7vA43f+PBS53Phnu9o55LDPUoE3Yu4k0BrHcOvub/GT60hsYBqIF98VfYZyjUX4MilRCfHPv 31ok/oa6XYouayxlx+J3YIrxjpw2OrXLjkjIjeADgo7KnAceHQXiEeI9G/x62kv5aXFf6Nnv0u8S MqsFHt34SlqxXAAAAAAAAA== --Apple-Mail-1--787137386-- From owner-atom-syntax@mail.imc.org Wed Aug 25 22:34:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16275 for ; Wed, 25 Aug 2004 22:34:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q2Q2qX034599; Wed, 25 Aug 2004 19:26:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q2Q2nR034598; Wed, 25 Aug 2004 19:26:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q2Q1m3034592 for ; Wed, 25 Aug 2004 19:26:01 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7Q2Q7IT009858; Wed, 25 Aug 2004 19:26:07 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i7Q2PqS1025555; Wed, 25 Aug 2004 19:26:03 -0700 (PDT) In-Reply-To: <1f2ed5cd0408251153319d3d9c@mail.gmail.com> References: <20040825182036.83573.qmail@web41202.mail.yahoo.com> <1f2ed5cd0408251153319d3d9c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--784162073; protocol="application/pkcs7-signature" Message-Id: <41D37C34-F707-11D8-8440-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceLinkRelMechanism Date: Wed, 25 Aug 2004 19:25:54 -0700 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--784162073 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Aug 2004, at 11:53 am, Danny Ayers wrote: > The most immediate gains are disambiguation and code reuse. This has already been completely debunked. The benefits here are minimal. Graham --Apple-Mail-2--784162073 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI2MDIyNTU0WjAjBgkqhkiG9w0BCQQxFgQU/zvYg1O+UB4ySCqmsixJk9Gz NVkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAAgYRcXB6/QS5pBeHCWQ1LCjq S+nQRYM4lMYq1JgJLzKnR6FLkg+ECFRelMm4s9euV0XMuHTUvx9r/tduAD1ix/sncCTiVpuBSilo iOGfPGnI0VyJ3OsM6eOMfu58uhIUNa53R7NwvySHibYbprK2t4W9iq0yiMIvDbw4NhL9MC3S6Ukq xsiaczbFsemsSIk15m5Qqon3joraEUHoGECfRsr5etqG3C512Her88MoOgjqm7NHHr0MoP8OI2Ku WKL33Yhy28WADpv4plohq/l/+NHAbjCbtwo42PMw88YAj2JF2QisVWCiTieFj9GtBtuPiM/O/y4I f4BCixPYv04rlQAAAAAAAA== --Apple-Mail-2--784162073-- From owner-atom-syntax@mail.imc.org Wed Aug 25 22:46:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16895 for ; Wed, 25 Aug 2004 22:46:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q2XkY8035456; Wed, 25 Aug 2004 19:33:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q2XkkO035455; Wed, 25 Aug 2004 19:33:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q2XjiY035449 for ; Wed, 25 Aug 2004 19:33:46 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] ([66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7Q2XslI027774; Wed, 25 Aug 2004 22:33:54 -0400 Message-ID: <412D4C0F.4030801@intertwingly.net> Date: Wed, 25 Aug 2004 22:33:51 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Atom-Syntax Subject: Re: ID wording References: <412CF511.9050007@gmx.de> <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <4.2.0.58.J.20040826082340.05b71bf0@localhost> <14be96d304082517583044d3ff@mail.gmail.com> <5466C310-F700-11D8-8440-000A95DC3D90@mac.com> In-Reply-To: <5466C310-F700-11D8-8440-000A95DC3D90@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > On 25 Aug 2004, at 5:58 pm, Mark Pilgrim wrote: > >> I understand that their only purpose is comparison. The >> counterintuitive part is that they look exactly like URIs, but you >> can't use your programming language's URI class to compare them. > > But it's equally conterintuitive that they're defined as URI but I can't > put a whole gamut of URIs in them because they don't fit a bunch of > arbitrary rules I don't have time to learn. Exactly which word in *ANY* of the following says that you *CAN'T*? http://www.imc.org/atom-syntax/mail-archive/msg08572.html http://www.imc.org/atom-syntax/mail-archive/msg08760.html http://www.intertwingly.net/wiki/pie/PaceIdConstruct - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 25 23:13:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18683 for ; Wed, 25 Aug 2004 23:13:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q31TcK037464; Wed, 25 Aug 2004 20:01:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q31TS3037462; Wed, 25 Aug 2004 20:01:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q31T3r037451 for ; Wed, 25 Aug 2004 20:01:29 -0700 (PDT) (envelope-from grayrest@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so286753rnk for ; Wed, 25 Aug 2004 20:01:27 -0700 (PDT) Received: by 10.38.171.20 with SMTP id t20mr2291378rne; Wed, 25 Aug 2004 20:01:27 -0700 (PDT) Received: by 10.38.70.69 with HTTP; Wed, 25 Aug 2004 20:01:27 -0700 (PDT) Message-ID: <476b71e804082520013c37a37c@mail.gmail.com> Date: Wed, 25 Aug 2004 23:01:27 -0400 From: grayrest Reply-To: grayrest To: Henry Story Subject: Re: URIs vs Strings Cc: Atom Syntax In-Reply-To: <3B11DBBF-F6E7-11D8-ADE0-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825222702.89095.qmail@web41214.mail.yahoo.com> <3B11DBBF-F6E7-11D8-ADE0-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My understanding was simply that 1. IDs must be unique and invariant 2. IDs must be compared as if they were strings 3. The easiest way to get a unique ID is to add something to an already unique value. The easiest unique string value to come across is a URI. A URI which, by definition, is unique if it is canoncial. It's too much work to do canonization, so we specify a string comparison. This has the added benefit of enabling IRIs and whatnot in the future. Am I missing something? Karl From owner-atom-syntax@mail.imc.org Wed Aug 25 23:42:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19413 for ; Wed, 25 Aug 2004 23:42:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q3XsPx039605; Wed, 25 Aug 2004 20:33:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q3Xs7v039604; Wed, 25 Aug 2004 20:33:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q3Xrc6039592 for ; Wed, 25 Aug 2004 20:33:53 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id UAA21237 for ; Wed, 25 Aug 2004 20:33:53 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id UAA27607 for ; Wed, 25 Aug 2004 20:33:52 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Wed, 25 Aug 2004 20:33:52 -0700 Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7Q3XnlB001927 for ; Wed, 25 Aug 2004 20:33:51 -0700 (PDT) Date: Wed, 25 Aug 2004 20:33:55 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: URIs vs Strings Message-ID: <7BAACFECB78D2190D5F5E131@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <476b71e804082520013c37a37c@mail.gmail.com> References: <20040825222702.89095.qmail@web41214.mail.yahoo.com> <3B11DBBF-F6E7-11D8-ADE0-000A95D9FA7A@bblfish.net> <476b71e804082520013c37a37c@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Wednesday, August 25, 2004 11:01 PM -0400 grayrest wrote: > > A URI which, by definition, is unique if it is canoncial. It's too > much work to do canonization, so we specify a string comparison. This > has the added benefit of enabling IRIs and whatnot in the future. > > Am I missing something? I think so. The canonicalization is done when the URI is created, not when it is compared. Normalized comparisons are optional. Each implementation only needs to follow the rules for the URI scheme(s) which it creates. It isn't "too much work". Any other URI created should also be in canonical form, so it isn't even extra code. Please, everyone, read the seven simple rules in the 2396bis draft. The purpose of these rules is to "minimize false-negatives" and to "minimize the amount of software processing" in comparisons. Those are our goals, too. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu Aug 26 01:51:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24520 for ; Thu, 26 Aug 2004 01:51:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q5iwci049496; Wed, 25 Aug 2004 22:44:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q5iwPH049495; Wed, 25 Aug 2004 22:44:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q5ivGx049487 for ; Wed, 25 Aug 2004 22:44:57 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 4950 invoked from network); 26 Aug 2004 05:51:07 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 26 Aug 2004 05:51:07 -0000 Subject: Re: URIs vs Strings From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Dare Obasanjo Cc: Henry Story , Atom syntax In-Reply-To: <20040825222702.89095.qmail@web41214.mail.yahoo.com> References: <20040825222702.89095.qmail@web41214.mail.yahoo.com> Content-Type: text/plain Message-Id: <1093499193.3389.13.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 26 Aug 2004 06:46:34 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-25 at 23:27, Dare Obasanjo wrote: > > Incorrect. Google for "DEC AND UUID" or "Microsoft AND > GUID". URIs provide a 'cheap' and 'easy' mechanism for > coming up with globally unique identifiers. They are > NOT the only way. +1. Makes more sense too. Loses this string comparator debate too. Uses less electrons in most cases. Meets more needs. Is garbage, so no one is likely to try and dereference it. Is more likely to be globally unique (practically). Is meant for just this class of problem. Downside, its so obvious.... NIH strikes? -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Thu Aug 26 01:51:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24632 for ; Thu, 26 Aug 2004 01:51:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q5fXYN048882; Wed, 25 Aug 2004 22:41:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q5fX0O048881; Wed, 25 Aug 2004 22:41:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q5fWxP048871 for ; Wed, 25 Aug 2004 22:41:32 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 4220 invoked from network); 26 Aug 2004 05:47:37 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 26 Aug 2004 05:47:37 -0000 Subject: Re: URIs vs Strings From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Julian Reschke Cc: Henry Story , Atom syntax In-Reply-To: <412D10B0.1010008@gmx.de> References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> Content-Type: text/plain Message-Id: <1093498986.3389.8.camel@homer> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 26 Aug 2004 06:43:07 +0100 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-08-25 at 23:20, Julian Reschke wrote: > Henry Story wrote: > > How can a blog writer find a globally unique string to identify his > > entry with? > > > > I think he absolutely cannot. Any string you find could have been found > > by someone else. In order to be able to make sure that a string is > > globally unique it has to be constructed according to rules that will > > guarantee uniqueness. And this means that only URI's (or URNs) can be > > used. There has to be a well defined construction mechanism. > > > > Is there anything I am missing in that argument? > > No, that's correct. You may be able to substitute "URI" by another > globally controlled scheme to create new IDs in a distributed manner > (like phone numbers + private extensions), but I guess URIs are the most > popular, flexible and and widely accepted way to achieve that goal. I still thinks its a valid question, " How can a blog writer find a globally unique string to identify his entry with?" Unless the writer owns a domain name, what do you think he or she will use when 'required' to produce a unique uri|l? -- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl From owner-atom-syntax@mail.imc.org Thu Aug 26 02:08:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03941 for ; Thu, 26 Aug 2004 02:08:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q61jHN052813; Wed, 25 Aug 2004 23:01:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q61jfb052812; Wed, 25 Aug 2004 23:01:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q61iAM052764 for ; Wed, 25 Aug 2004 23:01:44 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id A2DEA7C2E7; Thu, 26 Aug 2004 08:52:29 +0200 (CEST) To: "Norman Walsh" Cc: Atom-Syntax Subject: Re: Feeds MUST have alternate links? References: <87smabifw7.fsf@nwalsh.com> Message-ID: Date: Thu, 26 Aug 2004 08:03:30 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <87smabifw7.fsf@nwalsh.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 25 Aug 2004 08:03:20 -0400, Norman Walsh wrote: > Why must I produce an alternate representation of the feed? I would like to repeat that question. I have no answer for it, at least. I will use Atom in _many_ scenarios where there aren't any alternative representation for either the feed or the entries. Why should I have to create an HTML page no one on the planet will request just to accomodate the specification? > I have a practical reason for asking. Someone asked me to produce a > feed for all the photographs on norman.walsh.name. I can do that, but > I'm not going to produce an HTML page that is an alternate > representation of that feed. I suppose I could, but I'd rather not and > I don't see why I should. +1. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 26 02:24:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10513 for ; Thu, 26 Aug 2004 02:24:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6FRjr055938; Wed, 25 Aug 2004 23:15:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6FRb9055937; Wed, 25 Aug 2004 23:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6FQeA055911 for ; Wed, 25 Aug 2004 23:15:26 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 23F477C2E7; Thu, 26 Aug 2004 09:06:16 +0200 (CEST) Date: Thu, 26 Aug 2004 08:17:19 +0200 To: "Antone Roundy" Subject: Re: Link requirements [was : Can atom be Del.icio.us?] Cc: Atom-Syntax References: <81395121-F6CA-11D8-AFC5-003065EA6144@geckotribe.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <81395121-F6CA-11D8-AFC5-003065EA6144@geckotribe.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 25 Aug 2004 13:11:01 -0600, Antone Roundy wrote: >> (1) Each atom:entry element must have one or more link elements >> associated with it. > > This fits current syndication usage as far as I'm aware. Syndication of ordinary blogs, yes. Syndication of absolutely all other types of resources on the web; no. > It's far from inconceivable that people could want to publish feed-only > blogs rather than blogs with feeds Indeed. > and that there could be other uses for feed-only publication, either of > which may or may not not have links associated with each entry. Or links associated with the feed. The feed and the entries will in such situations be the first-class resources and not just XML-wrappers for other resources. I would want to use Atom like that in many cases. > Perhaps a good question is, if an entry doesn't have a link--if it is > entirely self-contained--does anything break? Off the top of my head, I > can't think of anything that that would really break. Me neither, so I see no reason to require that link; not for the feed and not for entries. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 26 02:29:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10657 for ; Thu, 26 Aug 2004 02:29:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6NL5A057327; Wed, 25 Aug 2004 23:23:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6NLZb057326; Wed, 25 Aug 2004 23:23:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6NKgh057302 for ; Wed, 25 Aug 2004 23:23:20 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 5FDE17C2EA; Thu, 26 Aug 2004 09:14:02 +0200 (CEST) To: "Graham Parks" Cc: Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <14be96d3040825142839283d2c@mail.gmail.com> <412D0FFD.4050908@gmx.de> <14be96d304082515441a82a0f9@mail.gmail.com> <12980955.1093475117092.JavaMail.dtcd@mac.com> Message-ID: Date: Thu, 26 Aug 2004 08:25:07 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <12980955.1093475117092.JavaMail.dtcd@mac.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 25 Aug 2004 19:05:17 -0400, Graham Parks wrote: > The problem is that there's more than one way to compare URIs, and not > all URI classes do the same thing. For consistency's sake we need to > specify one method, and we're specifying the simplest. I agree. Consumers should do string comparison. > Canonicalization has been suggested as an alternative solution (right?). No, that's not an alternative. Consumers should do _nothing_ else with the URI than treat it as any other string. No normalization, no canonicalization, no nothing. This is up to the _publisher_ to do, so that all atom:id's are correctly canonicalized when the consumer is fetching them to do comparison. > I see how that would work, but I much prefer the simplicity of the above > solution. Simplicity for consumers is good in this area, for consumers it sucks, because it will create inconsistent atom:id URI's since they aren't required to be canonicalized. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 26 02:35:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10740 for ; Thu, 26 Aug 2004 02:35:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6Rx3j058663; Wed, 25 Aug 2004 23:27:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6Rxt1058662; Wed, 25 Aug 2004 23:27:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6RwJU058636 for ; Wed, 25 Aug 2004 23:27:59 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id C1F087C2EA; Thu, 26 Aug 2004 09:18:40 +0200 (CEST) To: "Julian Reschke" Cc: Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> Message-ID: Date: Thu, 26 Aug 2004 08:29:47 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412CF511.9050007@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 25 Aug 2004 22:22:41 +0200, Julian Reschke wrote: > Yes. Just state that they are plain strings using URI syntax > (absoluteURI production in RFC2396) and that they are to be compared > character-by-character. This is wording for the consumers. What about wording for the producers? Is there any good reasons to not recommend or require publishers to put canonicalized URI's in atom:id? > I'm not against canonicalization; but if the spec mentions it there > should be a clear benefit in doing it. The clear benefit of recommending (SHOULD) or requiring (MUST) publishers to do it is to prevent inconsistent URI's in atom:id. Since atom:id is supposed to be immutable, that should be a goal, imho. > Saying "the IDs will work better when recipients break the spec when > comparing them" I have never said that recipients (consumers) should do anything special with atom:id URI's. I have said that producers should. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 26 02:41:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10867 for ; Thu, 26 Aug 2004 02:41:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6TI1M059100; Wed, 25 Aug 2004 23:29:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6TIrG059099; Wed, 25 Aug 2004 23:29:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6TH49059073 for ; Wed, 25 Aug 2004 23:29:18 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 90C877C2EA; Thu, 26 Aug 2004 09:19:59 +0200 (CEST) To: "Julian Reschke" Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> Message-ID: Date: Thu, 26 Aug 2004 08:31:05 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412CF547.5020704@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke wrote: > If consumers compare them as strings anyway, there's no point in > requiring canonicalization, right? Of course there is. If not, producers might use 'http://EXAMPLE.COM/232' as atom:id one place, and 'http://example.com/232' another place. By URI rules, those are the same, as strings they're not. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 26 02:46:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10891 for ; Thu, 26 Aug 2004 02:46:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6d18V061022; Wed, 25 Aug 2004 23:39:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6d1Ku061021; Wed, 25 Aug 2004 23:39:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6d0Jb061012 for ; Wed, 25 Aug 2004 23:39:01 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so220829rnb for ; Wed, 25 Aug 2004 23:39:00 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2507411rnh; Wed, 25 Aug 2004 23:39:00 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Wed, 25 Aug 2004 23:39:00 -0700 (PDT) Message-ID: <1f2ed5cd0408252339734dbd92@mail.gmail.com> Date: Thu, 26 Aug 2004 08:39:00 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: PaceLinkRelMechanism Cc: Atom Syntax In-Reply-To: <41D37C34-F707-11D8-8440-000A95DC3D90@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825182036.83573.qmail@web41202.mail.yahoo.com> <1f2ed5cd0408251153319d3d9c@mail.gmail.com> <41D37C34-F707-11D8-8440-000A95DC3D90@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 25 Aug 2004 19:25:54 -0700, Graham wrote: > On 25 Aug 2004, at 11:53 am, Danny Ayers wrote: > > > The most immediate gains are disambiguation and code reuse. > > This has already been completely debunked. No it hasn't, though you're welcome to try. You get disambiguation because because the structure is clearly defined unlike adding arbitrary namespaced elements/attributes anywhere. It allows code reuse because the same subsystem for dispatching behaviour from core elements can be reused to handle dispatching for other rel values. Using arbitrary namespaced elements/attributes anywhere demands that for every new construct, new code will be needed. I honestly can't see why you have a problem with the notion of using a common XML construct for a common range of data structures encountered in syndication feeds. The benefits here are > minimal. That depends on specific requirements. I would like to use Atom for more than simple news publishing/reading (or at least containing a wider range of information, like the Nature feeds). In these circumstances the benefits are great. If you really believe that this approach doesn't offer any gain, then it would be more productive if you could offer an alternative approach to handling the kind of richness commonly found in RSS 1.0 feeds in Atom in a systematic fashion. Or give a very good reason why Atom shouldn't be able to do this - handling extensions is in the charter. Cheers, Danny. From owner-atom-syntax@mail.imc.org Thu Aug 26 02:50:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11231 for ; Thu, 26 Aug 2004 02:50:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6gmMD062167; Wed, 25 Aug 2004 23:42:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6gmT9062166; Wed, 25 Aug 2004 23:42:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6glFc062141 for ; Wed, 25 Aug 2004 23:42:47 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 175B57C2EA; Thu, 26 Aug 2004 09:33:29 +0200 (CEST) To: "Julian Reschke" Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <14be96d30408251414192f892a@mail.gmail.com> <412D0F95.8030502@gmx.de> Message-ID: Date: Thu, 26 Aug 2004 08:44:38 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412D0F95.8030502@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 00:15:49 +0200, Julian Reschke wrote: > Well, if the spec tells them that the ID is a *string* that has URI > syntax, and that it needs to be compared as a string, I don't see a > problem. As a matter of fact, this has *provably* worked for XML > namespaces (show me one XML+NS processor that gets this wrong!), so why > shouldn't it work for something else? Because Bob doesn't have the same technical skills or knowledge as the people creating XML processors have. Bob will be a valuable consumer and producer of Atom feeds. Why shouldn't Bob get help from the specification to get this right? If the spec is silent on the issue, he will get it wrong. Not to mention the ViewSourceClan. How do you expect them to consume Atom feeds correctly, if the publishers aren't gently forced to do things as interoperable and correctly as possible? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 26 02:59:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11954 for ; Thu, 26 Aug 2004 02:59:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6qdDK064108; Wed, 25 Aug 2004 23:52:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6qdK2064107; Wed, 25 Aug 2004 23:52:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q6qbRc064084 for ; Wed, 25 Aug 2004 23:52:38 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 26899 invoked by uid 65534); 26 Aug 2004 06:52:32 -0000 Received: from pD9E51DCD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.205) by mail.gmx.net (mp002) with SMTP; 26 Aug 2004 08:52:32 +0200 X-Authenticated: #1915285 Message-ID: <412D88A8.9030503@gmx.de> Date: Thu, 26 Aug 2004 08:52:24 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Martin Duerst , asbjorn@tigerstaden.no, Atom-Syntax Subject: Re: ID wording References: <412CF511.9050007@gmx.de> <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <4.2.0.58.J.20040826082340.05b71bf0@localhost> <14be96d304082517583044d3ff@mail.gmail.com> In-Reply-To: <14be96d304082517583044d3ff@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > I understand that their only purpose is comparison. The > counterintuitive part is that they look exactly like URIs, but you > can't use your programming language's URI class to compare them. > > http://intertwingly.net/blog/2004/07/31/URI-Equivalence > > I guess Julian doesn't use languages like Java and C#, but I hear > they're catching on. Please stop guessing. Thanks, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 03:01:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12202 for ; Thu, 26 Aug 2004 03:01:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6s1R6064360; Wed, 25 Aug 2004 23:54:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6s1uT064359; Wed, 25 Aug 2004 23:54:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q6s0rJ064317 for ; Wed, 25 Aug 2004 23:54:00 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 11541 invoked by uid 65534); 26 Aug 2004 06:53:54 -0000 Received: from pD9E51DCD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.205) by mail.gmx.net (mp018) with SMTP; 26 Aug 2004 08:53:54 +0200 X-Authenticated: #1915285 Message-ID: <412D8900.9080006@gmx.de> Date: Thu, 26 Aug 2004 08:53:52 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: davep@dpawson.co.uk CC: Henry Story , Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> In-Reply-To: <1093498986.3389.8.camel@homer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave Pawson wrote: > I still thinks its a valid question, > " How can a blog writer find a globally unique string to identify his > entry with?" > > Unless the writer owns a domain name, what do you think he or she will > use when 'required' to produce a unique uri|l? We can give then a utility or a web page that generates one for them. For instance, a urn:uuid if it ever gets approved. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 03:05:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12588 for ; Thu, 26 Aug 2004 03:05:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q6utnd065117; Wed, 25 Aug 2004 23:56:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q6utHC065116; Wed, 25 Aug 2004 23:56:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q6usoZ065067 for ; Wed, 25 Aug 2004 23:56:55 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 19508 invoked by uid 65534); 26 Aug 2004 06:56:48 -0000 Received: from pD9E51DCD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.205) by mail.gmx.net (mp023) with SMTP; 26 Aug 2004 08:56:48 +0200 X-Authenticated: #1915285 Message-ID: <412D89AE.5060504@gmx.de> Date: Thu, 26 Aug 2004 08:56:46 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Wed, 25 Aug 2004 22:22:41 +0200, Julian Reschke > wrote: > >> Yes. Just state that they are plain strings using URI syntax >> (absoluteURI production in RFC2396) and that they are to be compared >> character-by-character. > > > This is wording for the consumers. What about wording for the > producers? Is there any good reasons to not recommend or require > publishers to put canonicalized URI's in atom:id? Yes, it doesn't help at all. Even if every atom ID is canonical, comparision results still can vary if people do not use identical comparison methods. On the other hand, if they do (and the method is string comparison), requiring canonicalization doesn't buy you anything and thus is useless. >> I'm not against canonicalization; but if the spec mentions it there >> should be a clear benefit in doing it. > > > The clear benefit of recommending (SHOULD) or requiring (MUST) > publishers to do it is to prevent inconsistent URI's in atom:id. Since > atom:id is supposed to be immutable, that should be a goal, imho. Define "inconsistent" in this context. >> Saying "the IDs will work better when recipients break the spec when >> comparing them" > > > I have never said that recipients (consumers) should do anything > special with atom:id URI's. I have said that producers should. Yes, but if consumers just do what the spec says, *it* *does* *not* *matter*. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 03:07:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12708 for ; Thu, 26 Aug 2004 03:07:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q700ev066282; Thu, 26 Aug 2004 00:00:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q700AQ066281; Thu, 26 Aug 2004 00:00:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q6xxbj066231 for ; Wed, 25 Aug 2004 23:59:59 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 11492 invoked by uid 65534); 26 Aug 2004 06:59:53 -0000 Received: from pD9E51DCD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.205) by mail.gmx.net (mp001) with SMTP; 26 Aug 2004 08:59:53 +0200 X-Authenticated: #1915285 Message-ID: <412D8A67.3070608@gmx.de> Date: Thu, 26 Aug 2004 08:59:51 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke > wrote: > >> If consumers compare them as strings anyway, there's no point in >> requiring canonicalization, right? > > > Of course there is. If not, producers might use > 'http://EXAMPLE.COM/232' as atom:id one place, and > 'http://example.com/232' another place. By URI rules, those are the > same, as strings they're not. Incorrect. By *one* of many ways to compare URIs, they are the same. There are multiple ways to compare URIs, and we just need to pick one. Speaking of which - how do you prevent people from using both http://example.com and http://example.com:80 if you just require canonicalization? Both are canonical, but for some (scheme-dependant) comparison methods (such as in a URI class that knows about http) they will compare identical. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 03:11:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13121 for ; Thu, 26 Aug 2004 03:11:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7281L067030; Thu, 26 Aug 2004 00:02:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q728eH067029; Thu, 26 Aug 2004 00:02:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q727Ze066997 for ; Thu, 26 Aug 2004 00:02:07 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 6580 invoked by uid 65534); 26 Aug 2004 07:02:02 -0000 Received: from pD9E51DCD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.205) by mail.gmx.net (mp024) with SMTP; 26 Aug 2004 09:02:02 +0200 X-Authenticated: #1915285 Message-ID: <412D8AE7.5080102@gmx.de> Date: Thu, 26 Aug 2004 09:01:59 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <14be96d30408251414192f892a@mail.gmail.com> <412D0F95.8030502@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Thu, 26 Aug 2004 00:15:49 +0200, Julian Reschke > wrote: > >> Well, if the spec tells them that the ID is a *string* that has URI >> syntax, and that it needs to be compared as a string, I don't see a >> problem. As a matter of fact, this has *provably* worked for XML >> namespaces (show me one XML+NS processor that gets this wrong!), so >> why shouldn't it work for something else? > > > Because Bob doesn't have the same technical skills or knowledge as the > people creating XML processors have. Bob will be a valuable consumer > and producer of Atom feeds. Why shouldn't Bob get help from the > specification to get this right? If the spec is silent on the issue, he > will get it wrong. It should not be silent. It should be crystal-clear. The best way to do that is to make it *simple*. An id is to be compared character-by-character. If this helps, add examples and a test suite. > Not to mention the ViewSourceClan. How do you expect them to consume > Atom feeds correctly, if the publishers aren't gently forced to do > things as interoperable and correctly as possible? How do you suggest to prevent the ViewSourceClan to re-use an atom ID (canonical or not) that they've seen in an existing document? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 03:12:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13202 for ; Thu, 26 Aug 2004 03:12:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q75vGV068012; Thu, 26 Aug 2004 00:05:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q75vpC068011; Thu, 26 Aug 2004 00:05:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q75uZ3067978 for ; Thu, 26 Aug 2004 00:05:56 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 0E3017C1EE; Thu, 26 Aug 2004 09:56:38 +0200 (CEST) Date: Thu, 26 Aug 2004 09:07:53 +0200 To: "Julian Reschke" Subject: Re: ID wording Cc: Atom-Syntax References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <412D89AE.5060504@gmx.de> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <412D89AE.5060504@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 08:56:46 +0200, Julian Reschke wrote: > Yes, it doesn't help at all. Even if every atom ID is canonical, > comparision results still can vary if people do not use identical > comparison methods. Who has been talking about different comparison methods? People should compare ID's in one way, at least internally. I really don't care whether they use URI or string comparison, and as long as the URI's are canonicalized, it won't matter either. > On the other hand, if they do (and the method is string comparison), > requiring canonicalization doesn't buy you anything and thus is useless. What canonicalization on the producer's side buys you, is that 'http://EXAMPLE.COM/1212' is an invalid or a should-not atom:id. > Define "inconsistent" in this context. 'http://EXAMPLE.COM/1212' and 'http://example.com/1212' are the same URI's, but different strings. That's inconsistent. Getting rid of the uppercase version of those two (which you do by requiring canonicalization) makes atom:id much more resilient to such inconsistency errors. >> I have never said that recipients (consumers) should do anything >> special with atom:id URI's. I have said that producers should. > > Yes, but if consumers just do what the spec says, *it* *does* *not* > *matter*. So in your book, 'http://EXAMPLE.COM/1212' and 'http://example.com/1212' are the same strings, or doesn't it matter that they're different? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 26 03:16:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13406 for ; Thu, 26 Aug 2004 03:16:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q78ect068930; Thu, 26 Aug 2004 00:08:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q78egx068929; Thu, 26 Aug 2004 00:08:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q78dbq068872 for ; Thu, 26 Aug 2004 00:08:39 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 402FB7C1EE; Thu, 26 Aug 2004 09:59:21 +0200 (CEST) To: "Julian Reschke" Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <412D8A67.3070608@gmx.de> Message-ID: Date: Thu, 26 Aug 2004 09:10:36 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412D8A67.3070608@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 08:59:51 +0200, Julian Reschke wrote: >> Of course there is. If not, producers might use >> 'http://EXAMPLE.COM/232' as atom:id one place, and >> 'http://example.com/232' another place. By URI rules, those are the >> same, as strings they're not. > > Incorrect. By *one* of many ways to compare URIs, they are the same. So now we don't only want people to compare atom:id as strings, but as case-insensitive strings. Correct? > There are multiple ways to compare URIs, and we just need to pick one. If we pick «compare as strings», casing matters. > Speaking of which - how do you prevent people from using both > > http://example.com > > and > > http://example.com:80 > > if you just require canonicalization? Both are canonical, but for some > (scheme-dependant) comparison methods (such as in a URI class that knows > about http) they will compare identical. 'http://example.com:80' is imho not canonical in regard to the HTTP scheme rules. The scheme's default port should be stripped, which makes 'http://example.com:80' into 'http://example.com'. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Aug 26 03:26:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13445 for ; Thu, 26 Aug 2004 03:26:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7KweK073496; Thu, 26 Aug 2004 00:20:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q7KwJS073495; Thu, 26 Aug 2004 00:20:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q7KuBY073460 for ; Thu, 26 Aug 2004 00:20:57 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 27534 invoked by uid 65534); 26 Aug 2004 07:20:51 -0000 Received: from pD9E51DCD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.205) by mail.gmx.net (mp019) with SMTP; 26 Aug 2004 09:20:51 +0200 X-Authenticated: #1915285 Message-ID: <412D8F51.8090508@gmx.de> Date: Thu, 26 Aug 2004 09:20:49 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <412D8A67.3070608@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: >> Incorrect. By *one* of many ways to compare URIs, they are the same. > > > So now we don't only want people to compare atom:id as strings, but as > case-insensitive strings. Correct? No. >> There are multiple ways to compare URIs, and we just need to pick one. > > > If we pick «compare as strings», casing matters. What I was referring to is the method defined in (case matters). >> Speaking of which - how do you prevent people from using both >> >> http://example.com >> >> and >> >> http://example.com:80 >> >> if you just require canonicalization? Both are canonical, but for >> some (scheme-dependant) comparison methods (such as in a URI class >> that knows about http) they will compare identical. > > > 'http://example.com:80' is imho not canonical in regard to the HTTP > scheme rules. The scheme's default port should be stripped, which > makes 'http://example.com:80' into 'http://example.com'. But now you're speaking of a vague term, not the one defined in . Where do I find the definition of "canonical" for an arbitrary URI scheme? What should the Atom spec actually say to require this scheme-dependant canonicalization? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 03:30:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13465 for ; Thu, 26 Aug 2004 03:30:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7Gott071851; Thu, 26 Aug 2004 00:16:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q7GoIf071850; Thu, 26 Aug 2004 00:16:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q7Gndp071826 for ; Thu, 26 Aug 2004 00:16:49 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 11594 invoked by uid 65534); 26 Aug 2004 07:16:43 -0000 Received: from pD9E51DCD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.205) by mail.gmx.net (mp019) with SMTP; 26 Aug 2004 09:16:43 +0200 X-Authenticated: #1915285 Message-ID: <412D8E57.8090001@gmx.de> Date: Thu, 26 Aug 2004 09:16:39 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: ID wording References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <412D89AE.5060504@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Thu, 26 Aug 2004 08:56:46 +0200, Julian Reschke > wrote: > >> Yes, it doesn't help at all. Even if every atom ID is canonical, >> comparision results still can vary if people do not use identical >> comparison methods. > > > Who has been talking about different comparison methods? People should > compare ID's in one way, at least internally. I really don't care > whether they use URI or string comparison, and as long as the URI's > are canonicalized, it won't matter either. a) There is *more* than one way to compare URIs. Some ways are scheme-dependant. b) Unless we pick a specific method (and that by definition needs to be independant of scheme), comparison results *will* vary, and this has nothing to do whatsoever with canonicalization. I just posted an example for that, and it would be appreciated if people would actually look at it and try to understand why requiring canonical URIs does NOT guarantee the same comparison results. >> On the other hand, if they do (and the method is string comparison), >> requiring canonicalization doesn't buy you anything and thus is useless. > > > What canonicalization on the producer's side buys you, is that > 'http://EXAMPLE.COM/1212' is an invalid or a should-not atom:id. > >> Define "inconsistent" in this context. > > > 'http://EXAMPLE.COM/1212' and 'http://example.com/1212' are the same > URI's, but different strings. That's inconsistent. Getting rid of the > uppercase version of those two (which you do by requiring > canonicalization) makes atom:id much more resilient to such > inconsistency errors. Speaking of "sameness" requires an agreed-upon comparison method. RFC2396bis defines a "ladder" of comparison methods, and when you speak of "same" you'll need to say under which comparison. If Atom defines string comparison (), the two identifiers above are indeed *not* the same. >>> I have never said that recipients (consumers) should do anything >>> special with atom:id URI's. I have said that producers should. >> >> >> Yes, but if consumers just do what the spec says, *it* *does* *not* >> *matter*. > > > So in your book, 'http://EXAMPLE.COM/1212' and > 'http://example.com/1212' are the same strings, or doesn't it matter > that they're different? They aren't the same strings, so they aren't the same IDs. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 04:46:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15372 for ; Thu, 26 Aug 2004 04:46:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8Wr0P093535; Thu, 26 Aug 2004 01:32:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q8WrvL093534; Thu, 26 Aug 2004 01:32:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8WqFk093514 for ; Thu, 26 Aug 2004 01:32:52 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so200827rnb for ; Thu, 26 Aug 2004 01:32:48 -0700 (PDT) Received: by 10.38.1.62 with SMTP id 62mr2546539rna; Thu, 26 Aug 2004 01:32:48 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 01:32:47 -0700 (PDT) Message-ID: <1f2ed5cd040826013223064844@mail.gmail.com> Date: Thu, 26 Aug 2004 10:32:47 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Julian Reschke Subject: Re: URIs vs Strings Cc: davep@dpawson.co.uk, Henry Story , Atom syntax In-Reply-To: <412D8900.9080006@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <412D8900.9080006@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [I mentioned this on another thread, but given the subject line of this thread I'll drop it in here as well if I may be so bold...] I fully support the use of URIs as the basis for Atom identifiers. Atom's primary environment is the web, URIs are the identifiers of the web. Encouraging canonicalization at source seems a good idea too. However, if the comparisons between these identifiers is to be based on string equivalence, then that is outside of the definition of URIs (in RFC 2396). So to be avoid inaccuracies in the Atom documentation, it may be useful to define a construct, URIstring, that shares all characteristics of URIs except identity comparisons are carried out char-by-char. Cheers, Danny. From owner-atom-syntax@mail.imc.org Thu Aug 26 05:09:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16770 for ; Thu, 26 Aug 2004 05:09:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8omgD097222; Thu, 26 Aug 2004 01:50:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q8omcA097221; Thu, 26 Aug 2004 01:50:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q8ok6t097185 for ; Thu, 26 Aug 2004 01:50:47 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 17451 invoked by uid 65534); 26 Aug 2004 08:50:41 -0000 Received: from p508247AC.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.71.172) by mail.gmx.net (mp019) with SMTP; 26 Aug 2004 10:50:41 +0200 X-Authenticated: #1915285 Message-ID: <412DA45C.20402@gmx.de> Date: Thu, 26 Aug 2004 10:50:36 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: davep@dpawson.co.uk, Henry Story , Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <412D8900.9080006@gmx.de> <1f2ed5cd040826013223064844@mail.gmail.com> In-Reply-To: <1f2ed5cd040826013223064844@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > [I mentioned this on another thread, but given the subject line of > this thread I'll drop it in here as well if I may be so bold...] > > I fully support the use of URIs as the basis for Atom identifiers. > Atom's primary environment is the web, URIs are the identifiers of the > web. Encouraging canonicalization at source seems a good idea too. > > However, if the comparisons between these identifiers is to be based > on string equivalence, then that is outside of the definition of URIs > (in RFC 2396). So to be avoid inaccuracies in the Atom documentation, > it may be useful to define a construct, URIstring, that shares all > characteristics of URIs except identity comparisons are carried out > char-by-char. RFC2396 clearly states in section 6 () that there is no scheme-independant equivalence definition. Thus we define the method; and this is clearly what we need to do if we want to avoid false positives. I *do* agree that it makes sense to have a construct that has the semantics of being a string that happens to have URI syntax. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 05:15:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17173 for ; Thu, 26 Aug 2004 05:15:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q8vZsq099362; Thu, 26 Aug 2004 01:57:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q8vZo9099361; Thu, 26 Aug 2004 01:57:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7Q8vYPP099341 for ; Thu, 26 Aug 2004 01:57:34 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 60198 messnum 3855401 invoked from network[83.70.40.79/83-70-40-79.bas2.prp.dublin.eircom.net]); 26 Aug 2004 08:57:28 -0000 Received: from 83-70-40-79.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.40.79) by mail08.svc.cra.dublin.eircom.net (qp 60198) with SMTP; 26 Aug 2004 08:57:28 -0000 Message-ID: <412DA5F2.7050305@dehora.net> Date: Thu, 26 Aug 2004 09:57:22 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom-Syntax Subject: Re: ID wording References: <412CF511.9050007@gmx.de> <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <4.2.0.58.J.20040826082340.05b71bf0@localhost> <14be96d304082517583044d3ff@mail.gmail.com> In-Reply-To: <14be96d304082517583044d3ff@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > I understand that their only purpose is comparison. The > counterintuitive part is that they look exactly like URIs, but you > can't use your programming language's URI class to compare them. > > http://intertwingly.net/blog/2004/07/31/URI-Equivalence > > I guess Julian doesn't use languages like Java and C#, but I hear > they're catching on. A major point of speccing strcmp is to protect developers from borked uricmp code. I use both Java and C#, and sometimes I use both in the same system. You can use their URI.eq calls; indeed we can't stop people using their URI.eq calls. Just don't expect the match quality to be the same as if we were using String.eq calls. Java at least, has a history of borked URI-related code going all the way back to 1.0 right up to 1.5 (~8 years). That's why a lot of people end up writing their own URI/URL classes in Java. I agree it is counterintuitive. But it less counterintuitive than tracing down lost matches to a URI/L.eq library call, realizing you can't fix it by subclassing because the class is sealed, then realizing you'll have to wait years for the bug to be fixed (if ever), then realizing you options are dynamic proxies, or rolling your own, or changing your code to use someone else's URI class that works (maybe). Ultimately the answer is to say to hell with with it and using String.eq and c14n. I've been through all this and it is a intensely stupifying and frustrating experience I wouldn't wish on anyone. Which is my way of saying not that we design against broken libraries, but that based on my experience, uricmp will be a significant burden that results in reduced data quality. Telling folks to use strcmp and/or having atom:id automapped onto string classes remains a major act of kindness on our part imo. And no, this does not belong in an implementors guide. If we are unable to be decisive and as result inflict a burden on those mapping IDs onto their programming language constructs, or those manipulating Atom, then we need to explain very clearly the consequences of certain choices. If we punt, then we tell people how to cope with our ineffectiveness. No guts, no glory. Winning scenario: mandate atom ids are compared are strings. Say stuff about using URIs to generate them. Comparison. Generation. Those are separate section headings folks. How hard do we have to make this? cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 26 06:46:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20322 for ; Thu, 26 Aug 2004 06:46:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QAaTuB022935; Thu, 26 Aug 2004 03:36:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QAaTN9022934; Thu, 26 Aug 2004 03:36:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bund.com.au (bund.com.au [203.18.243.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QAaStC022919 for ; Thu, 26 Aug 2004 03:36:28 -0700 (PDT) (envelope-from mjs@beebo.org) Received: from localhost (localhost [127.0.0.1]) by bund.com.au (Postfix) with ESMTP id ED8DA7E16; Thu, 26 Aug 2004 20:36:28 +1000 (EST) Received: from bund.com.au ([127.0.0.1]) by localhost (bund.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30810-05; Thu, 26 Aug 2004 20:36:25 +1000 (EST) Received: from bund.com.au (localhost [127.0.0.1]) by bund.com.au (Postfix) with ESMTP id B08C07D6D; Thu, 26 Aug 2004 20:36:25 +1000 (EST) Received: from 217.154.209.180 (SquirrelMail authenticated user mjs); by bund.com.au with HTTP; Thu, 26 Aug 2004 11:36:25 +0100 (BST) Message-ID: <2711.217.154.209.180.1093516585.squirrel@217.154.209.180> In-Reply-To: <14be96d3040825142839283d2c@mail.gmail.com> References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <14be96d3040825142839283d2c@mail.gmail.com> Date: Thu, 26 Aug 2004 11:36:25 +0100 (BST) Subject: Re: ID wording From: "Michael Stillwell" To: atom-syntax@vpnc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at bund.com.au Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Mark Pilgrim said: > > On Wed, 25 Aug 2004 22:22:41 +0200, Julian Reschke > wrote: >> Yes. Just state that they are plain strings using URI syntax >> (absoluteURI production in RFC2396) and that they are to be compared >> character-by-character. > > What you are advocating is what I listed as alternate solution #2 in > my recent message: "atom:id MUST be a URI, except you can't use your > URI class to compare it... oh, and you can't do anything else with > atom:ids except compare them." This is counterintuitive. Can't the canonicalisation issue be avoided by simply using a URI scheme other than "http" for ids? (Or can't feed producers who dislike the canonicalisation stuff individually choose to do so?) Canonicalisation rules exist for the http scheme, but not for all schemes, and URI classes will surely only attempt to canonicalise schemes they know about. I can imagine that URI classes would consider "http://example.com" and "http://EXAMPLE.COM" to be the same, for example, but any that considers "atomid:example.com" and "atomid:EXAMPLE.COM" to be so is very broken. i.e. define a URI of scheme "atomid" to be "atomid:" + some string. (I realise this is almost the same as just "some string," but some people seem really keen on URIs as ids...) RFC2696bis says (note the "with respect to their scheme"): "Those who produce and make reference to URIs can reduce the cost of processing and the risk of false negatives by consistently providing them in a form that is reasonably canonical with respect to their scheme." http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#canonical-form (I also think it's counterintuitive for an id to look like something you can type into your browser's location field; switching to (or recommending) a different scheme would also eliminate this problem.) --M. -- http://beebo.org From owner-atom-syntax@mail.imc.org Thu Aug 26 06:48:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20400 for ; Thu, 26 Aug 2004 06:48:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QAbfbL023202; Thu, 26 Aug 2004 03:37:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QAbfHx023201; Thu, 26 Aug 2004 03:37:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QAbeZ1023183 for ; Thu, 26 Aug 2004 03:37:40 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7QAbiLj020188; Thu, 26 Aug 2004 06:37:44 -0400 Message-ID: <412DBD74.9040904@intertwingly.net> Date: Thu, 26 Aug 2004 06:37:40 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Norman Walsh , Atom-Syntax Subject: Re: Feeds MUST have alternate links? References: <87smabifw7.fsf@nwalsh.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Wed, 25 Aug 2004 08:03:20 -0400, Norman Walsh wrote: > >> Why must I produce an alternate representation of the feed? > > I would like to repeat that question. I have no answer for it, at least. > I will use Atom in _many_ scenarios where there aren't any alternative > representation for either the feed or the entries. Why should I have to > create an HTML page no one on the planet will request just to > accomodate the specification? > >> I have a practical reason for asking. Someone asked me to produce a >> feed for all the photographs on norman.walsh.name. I can do that, but >> I'm not going to produce an HTML page that is an alternate >> representation of that feed. I suppose I could, but I'd rather not and >> I don't see why I should. > > +1. Let me point out that the channel link element is required in every version of RSS from 0.91 to 1.0 to 2.0. And as a co-author of the feedvalidator, I have seen a lot of broken feeds where people have either inadvertently or deliberately ignored the specification, but I don't recall ever seeing one where this element was not present. http://my.netscape.com/publish/formats/rss-spec-0.91.html#channel http://web.resource.org/rss/1.0/spec#s5.3 http://blogs.law.harvard.edu/tech/rss#requiredChannelElements http://feedvalidator.org/docs/error/MissingLink.html - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 26 06:56:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20928 for ; Thu, 26 Aug 2004 06:56:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QAnHqC026378; Thu, 26 Aug 2004 03:49:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QAnHJi026377; Thu, 26 Aug 2004 03:49:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QAnGih026367 for ; Thu, 26 Aug 2004 03:49:16 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7QAn6Ve020764; Thu, 26 Aug 2004 06:49:06 -0400 Message-ID: <412DC01E.3030505@intertwingly.net> Date: Thu, 26 Aug 2004 06:49:02 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <412D8A67.3070608@gmx.de> In-Reply-To: <412D8A67.3070608@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Speaking of which - how do you prevent people from using both > > http://example.com > > and > > http://example.com:80 > > if you just require canonicalization? Both are canonical, but for some > (scheme-dependant) comparison methods (such as in a URI class that knows > about http) they will compare identical. "For schemes that define a port, use an empty port if the default is desired" http://www.intertwingly.net/wiki/pie/PaceIdConstruct http://www.intertwingly.net/blog/2004/08/04/Urlnorm The proposal is to put the former into the spec, the latter into the feedvalidator. The expectation is that few will see this warning, and those that do are free to ignore it. - Sam Ruby P.S.: the Equals method in the System.Uri class in the .Net CLR will return True with the example URIs listed above. From owner-atom-syntax@mail.imc.org Thu Aug 26 07:15:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21831 for ; Thu, 26 Aug 2004 07:15:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QB6RWC029605; Thu, 26 Aug 2004 04:06:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QB6ROY029604; Thu, 26 Aug 2004 04:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QB6PI0029585 for ; Thu, 26 Aug 2004 04:06:26 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 17076 invoked by uid 65534); 26 Aug 2004 11:06:22 -0000 Received: from p508247AC.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.71.172) by mail.gmx.net (mp020) with SMTP; 26 Aug 2004 13:06:22 +0200 X-Authenticated: #1915285 Message-ID: <412DC42C.20703@gmx.de> Date: Thu, 26 Aug 2004 13:06:20 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <412D8A67.3070608@gmx.de> <412DC01E.3030505@intertwingly.net> In-Reply-To: <412DC01E.3030505@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Julian Reschke wrote: > >> >> Speaking of which - how do you prevent people from using both >> >> http://example.com >> >> and >> >> http://example.com:80 >> >> if you just require canonicalization? Both are canonical, but for some >> (scheme-dependant) comparison methods (such as in a URI class that >> knows about http) they will compare identical. > > > "For schemes that define a port, use an empty port if the default is > desired" > > http://www.intertwingly.net/wiki/pie/PaceIdConstruct > http://www.intertwingly.net/blog/2004/08/04/Urlnorm OK, this is something that goes beyond what RFC2396bis defines. Anyway; consider http://example.com:81 and http://example.com:081 No matter how hard you try defining a canonical form, there will always be room for IDs that have different "canonical" forms but will compare equal for some implementation that simply knows more about equivalence for that URI scheme than a generic canonicalization can specify. > The proposal is to put the former into the spec, the latter into the > feedvalidator. The expectation is that few will see this warning, and > those that do are free to ignore it. > > - Sam Ruby > > P.S.: the Equals method in the System.Uri class in the .Net CLR will > return True with the example URIs listed above. Yes, but would it also for webcal://example.com and webcal://example.com:80 ? The point being: assumptions about what URI classes will state on various platforms do not help. These may vary over time (releases), platforms, installed URI schemes. We should not rely on those, therefore we require simple string comparison. And if we do that, canonicalization does not give us anything in addition (except a more complex and harder to explain spec). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 10:32:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04376 for ; Thu, 26 Aug 2004 10:32:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEJFHZ078054; Thu, 26 Aug 2004 07:19:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QEJFxj078053; Thu, 26 Aug 2004 07:19:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEJEkQ078012 for ; Thu, 26 Aug 2004 07:19:14 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so170101rnl for ; Thu, 26 Aug 2004 07:19:11 -0700 (PDT) Received: by 10.38.72.60 with SMTP id u60mr1319867rna; Thu, 26 Aug 2004 07:19:11 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Thu, 26 Aug 2004 07:19:11 -0700 (PDT) Message-ID: <14be96d3040826071922d4fd90@mail.gmail.com> Date: Thu, 26 Aug 2004 10:19:11 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: davep@dpawson.co.uk Subject: Re: URIs vs Strings Cc: Atom syntax In-Reply-To: <1093498986.3389.8.camel@homer> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 06:43:07 +0100, Dave Pawson wrote: > I still thinks its a valid question, > " How can a blog writer find a globally unique string to identify his > entry with?" > > Unless the writer owns a domain name, what do you think he or she will > use when 'required' to produce a unique uri|l? tag: URIs use a combination of a domain name + a date on which you controlled that domain as the starting point for constructing a globally unique ID. In the absence of a domain name, an email address that you controlled on that date would also suffice. (This is mentioned explicitly in the spec.) The usual suspects will now pounce on me and warn (correctly) that tag: URIs are not a registered URI scheme. But that doesn't negate the fact that it is relatively simple to create globally unique IDs. All you need is something that is globally unique at a moment in time, plus the moment in time. Both of these are readily available. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu Aug 26 10:32:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04479 for ; Thu, 26 Aug 2004 10:32:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEPebR080027; Thu, 26 Aug 2004 07:25:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QEPepk080026; Thu, 26 Aug 2004 07:25:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEPdfi080008 for ; Thu, 26 Aug 2004 07:25:39 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so211329rnb for ; Thu, 26 Aug 2004 07:25:36 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2690521rnh; Thu, 26 Aug 2004 07:25:36 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 07:25:36 -0700 (PDT) Message-ID: <1f2ed5cd040826072545ffc23a@mail.gmail.com> Date: Thu, 26 Aug 2004 16:25:36 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Michael Stillwell Subject: Re: ID wording Cc: atom-syntax@vpnc.org In-Reply-To: <2711.217.154.209.180.1093516585.squirrel@217.154.209.180> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <14be96d3040825142839283d2c@mail.gmail.com> <2711.217.154.209.180.1093516585.squirrel@217.154.209.180> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 11:36:25 +0100 (BST), Michael Stillwell wrote: > Can't the canonicalisation issue be avoided by simply using a URI scheme > other than "http" for ids? (Or can't feed producers who dislike the > canonicalisation stuff individually choose to do so?) Perhaps, though it would need the introduction of corresponding URI-building tools in every producer. Which is probably about the same complication as producing canonical URIs. > Canonicalisation rules exist for the http scheme, but not for all > schemes, and URI classes will surely only attempt to canonicalise schemes > they know about. I can imagine that URI classes would consider > "http://example.com" and "http://EXAMPLE.COM" to be the same, for > example, but any that considers "atomid:example.com" and > "atomid:EXAMPLE.COM" to be so is very broken. i.e. define a URI of > scheme "atomid" to be "atomid:" + some string. (I realise this is almost > the same as just "some string," but some people seem really keen on URIs > as ids...) URIs are the identifiers of the web, Atom's primary environment. > RFC2696bis says (note the "with respect to their scheme"): "Those who > produce and make reference to URIs can reduce the cost of processing and > the risk of false negatives by consistently providing them in a form that > is reasonably canonical with respect to their scheme." > http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#canonical-form > > (I also think it's counterintuitive for an id to look like something you > can type into your browser's location field; switching to (or > recommending) a different scheme would also eliminate this problem.) How often do people type new things into the location field? I only usually do it to get the name-completion bit of Firefox to remember places I've already been. The counter-intuitive bit is giving resources on the web (which usually have HTTP-retrievable representations) URIs that by design won't give access to a representation. I think the sweetspot between being 'correct' (using URIs according to rfc2396bis, noting that many code libs are borked) and 'simple' is to use the modified form of URI, where comparison is char-by-char. It would have to be made clear that these aren't really URIs, and probably advise producers to use the canonical form - it's in their own interests not to flood aggregator windows with duplicates after all. Cheers, Danny. From owner-atom-syntax@mail.imc.org Thu Aug 26 10:34:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04989 for ; Thu, 26 Aug 2004 10:34:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEO4sI079567; Thu, 26 Aug 2004 07:24:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QEO4K9079566; Thu, 26 Aug 2004 07:24:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEO4ul079534 for ; Thu, 26 Aug 2004 07:24:04 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so324497rnk for ; Thu, 26 Aug 2004 07:24:01 -0700 (PDT) Received: by 10.38.102.54 with SMTP id z54mr2220191rnb; Thu, 26 Aug 2004 07:24:00 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Thu, 26 Aug 2004 07:23:59 -0700 (PDT) Message-ID: <14be96d3040826072342458b97@mail.gmail.com> Date: Thu, 26 Aug 2004 10:23:59 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Sam Ruby Subject: Re: Feeds MUST have alternate links? Cc: "Asbjørn Ulsberg" , Norman Walsh , Atom-Syntax In-Reply-To: <412DBD74.9040904@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <87smabifw7.fsf@nwalsh.com> <412DBD74.9040904@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 06:37:40 -0400, Sam Ruby wrote: > Let me point out that the channel link element is required in every > version of RSS from 0.91 to 1.0 to 2.0. Correction: it was also required in RSS 0.90. http://www.purplepages.ie/RSS/netscape/rss0.90.html -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu Aug 26 10:43:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06396 for ; Thu, 26 Aug 2004 10:43:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEYAXV082565; Thu, 26 Aug 2004 07:34:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QEYAxJ082564; Thu, 26 Aug 2004 07:34:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEYAOe082522 for ; Thu, 26 Aug 2004 07:34:10 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so234615rnb for ; Thu, 26 Aug 2004 07:34:07 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2695219rnh; Thu, 26 Aug 2004 07:34:07 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 07:34:07 -0700 (PDT) Message-ID: <1f2ed5cd0408260734406545f6@mail.gmail.com> Date: Thu, 26 Aug 2004 16:34:07 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: Feeds MUST have alternate links? Cc: "Asbjørn Ulsberg" , Norman Walsh , Atom-Syntax In-Reply-To: <412DBD74.9040904@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <87smabifw7.fsf@nwalsh.com> <412DBD74.9040904@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7QEYAOe082559 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 06:37:40 -0400, Sam Ruby wrote: > > Asbjørn Ulsberg wrote: > > > > On Wed, 25 Aug 2004 08:03:20 -0400, Norman Walsh wrote: Why should I have to > > create an HTML page no one on the planet will request just to > > accomodate the specification? > > +1. Without considerably more justification, that gets my +1 too. > Let me point out that the channel link element is required in every > version of RSS from 0.91 to 1.0 to 2.0. Mark kindly supplied the perfect response to this a few weeks ago: http://www.rider.edu/~suler/zenstory/ritualcat.html Cheers, Danny. From owner-atom-syntax@mail.imc.org Thu Aug 26 11:01:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08178 for ; Thu, 26 Aug 2004 11:01:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QElIYf085708; Thu, 26 Aug 2004 07:47:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QElI00085707; Thu, 26 Aug 2004 07:47:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QElIqt085699 for ; Thu, 26 Aug 2004 07:47:18 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 80265 invoked by uid 17064); 26 Aug 2004 14:47:20 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.128.186]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 26 Aug 2004 14:47:20 -0000 In-Reply-To: <14be96d3040826071922d4fd90@mail.gmail.com> References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Mark Pilgrim From: Henry Story Subject: Re: URIs vs Strings Date: Thu, 26 Aug 2004 16:47:17 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Aug 2004, at 16:19, Mark Pilgrim wrote: > > The usual suspects will now pounce on me and warn (correctly) that > tag: URIs are not a registered URI scheme. But that doesn't negate > the fact that it is relatively simple to create globally unique IDs. > All you need is something that is globally unique at a moment in time, > plus the moment in time. Both of these are readily available. Just for the sake of further clarification... To be even more precise, should that not be: All you need is: 1- something that is globally unique at a moment in time 2- a relation that relates you to that thing uniquely at that time 3- a method of constructing an id with that relationship For example the empire state building is unique. But for me to be able to be an ID creator there has to be a relation between me and the empire state building that can in some way be constructed, or else anyone could claim a similar relationship to that building, and so I would have no guarantee that the ID I created was indeed unique. The tag scheme (which is not iana registered) works by taking a globally referenceable property of yours (a domain name, web page url perhaps) at a moment in time, specifying the moment, and adding some extra data of your choosing in order to give you a unique id. If we each had ID numbers like our social security number we could also create our tags that way, eg sstag:us:1203124143:/blog/1231 Henry > > -- > Cheers, > -Mark > From owner-atom-syntax@mail.imc.org Thu Aug 26 11:09:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09036 for ; Thu, 26 Aug 2004 11:09:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QF0NxN089384; Thu, 26 Aug 2004 08:00:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QF0NO3089383; Thu, 26 Aug 2004 08:00:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QF0MY7089346 for ; Thu, 26 Aug 2004 08:00:22 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so236262rnb for ; Thu, 26 Aug 2004 08:00:17 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2709155rnh; Thu, 26 Aug 2004 08:00:16 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 08:00:16 -0700 (PDT) Message-ID: <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> Date: Thu, 26 Aug 2004 17:00:16 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Mark Pilgrim Subject: Re: URIs vs Strings Cc: davep@dpawson.co.uk, Atom syntax In-Reply-To: <14be96d3040826071922d4fd90@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 10:19:11 -0400, Mark Pilgrim wrote: > The usual suspects will now pounce on me and warn (correctly) that > tag: URIs are not a registered URI scheme. But that doesn't negate > the fact that it is relatively simple to create globally unique IDs. > All you need is something that is globally unique at a moment in time, > plus the moment in time. Both of these are readily available. [pounce] But assuming that the current (misguided, IMHO) approach of advocating non-HTTP resolvable IDs continues, then tag: URIs are technically ideal. The consensus is to base Atom ids on URIs, whether to use the comparison ladder or to flatten it to a string. Ok, so the spec shouldn't recommend the use of the tag: scheme until it's registered. But that still fits with the proposed solutions. If people choose to use it in practice, I'm not going to lose much sleep. It might even be a good thing, to help get tag: registered. Having said all that, allow me to turn the argument around a little. Why should the the tag: scheme need to be registered? If Atom's id uses string comparison rather than rfc2396's definition of equivalence it's not a URI anyway. Cheers, Danny. From owner-atom-syntax@mail.imc.org Thu Aug 26 11:14:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09476 for ; Thu, 26 Aug 2004 11:14:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QEvfPH088514; Thu, 26 Aug 2004 07:57:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QEvfGu088513; Thu, 26 Aug 2004 07:57:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QEvemW088478 for ; Thu, 26 Aug 2004 07:57:40 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040826145735.79336.qmail@web41206.mail.yahoo.com> Received: from [67.160.81.108] by web41206.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 07:57:35 PDT Date: Thu, 26 Aug 2004 07:57:35 -0700 (PDT) From: Dare Obasanjo Subject: Re: Feeds MUST have alternate links? To: Sam Ruby , "Asbjørn_Ulsberg" Cc: Norman Walsh , Atom-Syntax In-Reply-To: <412DBD74.9040904@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Sam Ruby wrote: > > >> I'm not going to produce an HTML page that is an > alternate > >> representation of that feed. I suppose I could, > but I'd rather not and > >> I don't see why I should. > > > > +1. > > Let me point out that the channel link element is > required in every > version of RSS from 0.91 to 1.0 to 2.0. > > And as a co-author of the feedvalidator, I have seen > a lot of broken > feeds where people have either inadvertently or > deliberately ignored the > specification, but I don't recall ever seeing one > where this element was > not present. The feedvalidator is primarily used for validating of websites. However many have claimed that Atom will be more than a site syndication format. For example, I'm in the process of adding NNTP support to RSS Bandit. I will archive USENET groups and RSS feeds in the same format. If I choose Atom as this format what would you suggest I use as the alternate link for the feed for microsoft.public.dotnet.xml? Would 'news:microsoft.public.dotnet.xml' be an acceptable value? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 26 11:18:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09794 for ; Thu, 26 Aug 2004 11:18:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFBBZw092897; Thu, 26 Aug 2004 08:11:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFBBQt092895; Thu, 26 Aug 2004 08:11:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFBAIL092850 for ; Thu, 26 Aug 2004 08:11:10 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0Lu5-0006cE-QH; Thu, 26 Aug 2004 15:11:05 +0000 Message-ID: <412DFD81.5000103@franklinmint.fm> Date: Thu, 26 Aug 2004 11:10:57 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Mark Pilgrim , davep@dpawson.co.uk, Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> In-Reply-To: <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > On Thu, 26 Aug 2004 10:19:11 -0400, Mark Pilgrim wrote: > > > Having said all that, allow me to turn the argument around a little. > Why should the the tag: scheme need to be registered? If Atom's id > uses string comparison rather than rfc2396's definition of equivalence > it's not a URI anyway. > http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison-string From owner-atom-syntax@mail.imc.org Thu Aug 26 11:18:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09871 for ; Thu, 26 Aug 2004 11:18:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFB81D092849; Thu, 26 Aug 2004 08:11:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFB74v092841; Thu, 26 Aug 2004 08:11:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFB62X092727 for ; Thu, 26 Aug 2004 08:11:06 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id IAA23999 for ; Thu, 26 Aug 2004 08:11:02 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id IAA05390 for ; Thu, 26 Aug 2004 08:11:01 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Thu, 26 Aug 2004 08:11:01 -0700 Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7QFAtlB004379 for ; Thu, 26 Aug 2004 08:10:59 -0700 (PDT) Date: Thu, 26 Aug 2004 08:11:01 -0700 From: Walter Underwood To: atom-syntax@vpnc.org Subject: Re: ID wording Message-ID: In-Reply-To: <2711.217.154.209.180.1093516585.squirrel@217.154.209.180> References: <4125ACA3.1070400@annevankesteren.nl> <4125B086.8040508@gmx.de> <4125B244.1090006@annevankesteren.nl> <4125B40B.3060505@gmx.de> <412707CE.3010609@gmx.de> <068D3592A6259E6DDEAEAA82@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <412A00A1.1060502@gmx.de> <412A0422.80404@intertwingly.net> <412A124E.6050705@gmx.de> <412ADD0D.6020300@gmx.de> <412CF511.9050007@gmx.de> <14be96d3040825142839283d2c@mail.gmail.com> <2711.217.154.209.180.1093516585.squirrel@217.154.209.180> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Thursday, August 26, 2004 11:36 AM +0100 Michael Stillwell wrote: > > Can't the canonicalisation issue be avoided by simply using a URI scheme > other than "http" for ids? (Or can't feed producers who dislike the > canonicalisation stuff individually choose to do so?) Legacy data doesn't have IDs, and making one up can make things worse (different IDs for the same entry, created in different feed software). There are RDF feeds around with HTTP URI IDs. So there is substantial advantage in allowing HTTP URIs as IDs. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu Aug 26 11:44:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12799 for ; Thu, 26 Aug 2004 11:44:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFbQrB001856; Thu, 26 Aug 2004 08:37:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFbQ9M001855; Thu, 26 Aug 2004 08:37:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QFbP6H001819 for ; Thu, 26 Aug 2004 08:37:25 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040826153723.22538.qmail@web41203.mail.yahoo.com> Received: from [67.160.81.108] by web41203.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 08:37:23 PDT Date: Thu, 26 Aug 2004 08:37:23 -0700 (PDT) From: Dare Obasanjo Subject: Follow the W3Cs Example (Re: URIs vs Strings) To: Danny Ayers , Mark Pilgrim Cc: davep@dpawson.co.uk, Atom syntax In-Reply-To: <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Danny Ayers wrote: > > Having said all that, allow me to turn the argument > around a little. > Why should the the tag: scheme need to be > registered? If Atom's id > uses string comparison rather than rfc2396's > definition of equivalence > it's not a URI anyway. Why are people going around and around on this? There is precedent for this behavior in http://www.w3.org/TR/REC-xml-names/ and http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference Basically the two major W3C specs that utilize URIs as identifiers define character by character comparison and don't require canonicalization Can we just move past this issue, please? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Thu Aug 26 11:48:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13089 for ; Thu, 26 Aug 2004 11:48:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFeECc002632; Thu, 26 Aug 2004 08:40:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFeE7p002631; Thu, 26 Aug 2004 08:40:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFeEx7002604 for ; Thu, 26 Aug 2004 08:40:14 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004082615401101600ju58he>; Thu, 26 Aug 2004 15:40:11 +0000 Date: Thu, 26 Aug 2004 09:40:09 -0600 Subject: Re: PaceIdConstruct Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <412CF547.5020704@gmx.de> Message-Id: <366A89BC-F776-11D8-ABD6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, August 25, 2004, at 02:23 PM, Julian Reschke wrote: > If consumers compare them as strings anyway, there's no point in > requiring canonicalization, right? What is our goal, and how to we maximize the probability of it being met? Goal: to be able to recognize an entry that we've seen before as being the same entry when we see it again (whether in the same feed or not, whether modified or not, no false positives and no false negatives) Required attributes of an id to meet this goal: 1) must be globally unique 2) must not change 3) must be able to compare ids unambiguously How we maximize the probability of achieving those attributes, and thus the goal: 1) use URIs for ids 2) tell people not to alter existing ids under any circumstances 3) mandate string comparison I think we can all agree on, or at least accept, the foregoing. Possible barriers: 2) a) dynamic id generation yielding different ids after a change in the system that generates them (it gets moved to a new domain, a change to a library, etc.) b) dynamic id generation yielding different ids because multiple systems are independently generating ids differently from the same data (one uses a library that includes port numbers, the other doesn't, etc.) Mandating that people store their IDs is an implementation detail that we don't want to get into (at least not most of us). So how do we maximize the probability of dynamically generated ids being minted the same way each time? By specifying not just canonicalization, but a specific set of canonicalization rules, hopefully prompting people to use code that they can be certain will generate ids according to those rules rather than trusting that the library they're using will do it right. A specific set of canonicalization rules also enables feed validators to tell people that the way they're minting ids is wrong (or at least, violates a SHOULD--we need to accomodate ids originating from systems with looser constraints, right?), prompting them to improve their minting system making it more likely to remain consistent if one of its ingredients changes. Questions: 1) Will requiring canonicalization according to a set of rules explicitly set out in the spec yield the benefits outlined above? 2) Will that be too onerous a burden for the benefits it yields? 3) Is there a better way to maximize the probability of meeting the goal? From owner-atom-syntax@mail.imc.org Thu Aug 26 11:59:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13810 for ; Thu, 26 Aug 2004 11:59:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFonKa005155; Thu, 26 Aug 2004 08:50:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFons0005153; Thu, 26 Aug 2004 08:50:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFonIA005119 for ; Thu, 26 Aug 2004 08:50:49 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so216382rnb for ; Thu, 26 Aug 2004 08:50:47 -0700 (PDT) Received: by 10.38.206.56 with SMTP id d56mr387031rng; Thu, 26 Aug 2004 08:50:46 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 08:50:46 -0700 (PDT) Message-ID: <1f2ed5cd0408260850a6def08@mail.gmail.com> Date: Thu, 26 Aug 2004 17:50:46 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Follow the W3Cs Example (Re: URIs vs Strings) Cc: Mark Pilgrim , davep@dpawson.co.uk, Atom syntax In-Reply-To: <20040826153723.22538.qmail@web41203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040826153723.22538.qmail@web41203.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Heh - you beat me to it. +1. On Thu, 26 Aug 2004 08:37:23 -0700 (PDT), Dare Obasanjo wrote: > > --- Danny Ayers wrote: > > > > Having said all that, allow me to turn the argument > > around a little. > > Why should the the tag: scheme need to be > > registered? If Atom's id > > uses string comparison rather than rfc2396's > > definition of equivalence > > it's not a URI anyway. > > Why are people going around and around on this? There > is precedent for this behavior in > http://www.w3.org/TR/REC-xml-names/ and > http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference > > Basically the two major W3C specs that utilize URIs as > identifiers define character by character comparison > and don't require canonicalization > > Can we just move past this issue, please? > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 > No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. > > > __________________________________ > Do you Yahoo!? > Y! Messenger - Communicate in real time. Download now. > http://messenger.yahoo.com > From owner-atom-syntax@mail.imc.org Thu Aug 26 12:04:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14299 for ; Thu, 26 Aug 2004 12:04:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFmdmC004520; Thu, 26 Aug 2004 08:48:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFmdcI004519; Thu, 26 Aug 2004 08:48:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFma3v004480 for ; Thu, 26 Aug 2004 08:48:39 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so239382rnb for ; Thu, 26 Aug 2004 08:48:34 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2735331rnh; Thu, 26 Aug 2004 08:48:34 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 08:48:34 -0700 (PDT) Message-ID: <1f2ed5cd04082608487ae082d6@mail.gmail.com> Date: Thu, 26 Aug 2004 17:48:34 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Henry Story Subject: URIrefs vs URIs vs Strings Cc: Atom Syntax , Mark Pilgrim In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd completely forgotten about this until trying to trace back what RSS 1.0 says about ids. If RSS 1.0 was updated to follow the current RDF specs, then its ids will actually be URIrefs, not URIs, and: "Two RDF URI references are equal if and only if they compare as equal, character by character, as Unicode strings." [1] Which suggests two questions: 1. Should http://example.org/foo#bar be considered the same id as http://example.org/foo#wub ? 2. Should Atom use URIrefs for IDs? [1] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference From owner-atom-syntax@mail.imc.org Thu Aug 26 12:06:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14396 for ; Thu, 26 Aug 2004 12:06:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QG0V5D007648; Thu, 26 Aug 2004 09:00:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QG0Vox007647; Thu, 26 Aug 2004 09:00:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QG0TxE007611 for ; Thu, 26 Aug 2004 09:00:31 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so240138rnb for ; Thu, 26 Aug 2004 09:00:24 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2742161rnh; Thu, 26 Aug 2004 09:00:23 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 09:00:23 -0700 (PDT) Message-ID: <1f2ed5cd04082609004e68cf87@mail.gmail.com> Date: Thu, 26 Aug 2004 18:00:23 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Follow the W3Cs Example (Re: URIs vs Strings) Cc: Mark Pilgrim , davep@dpawson.co.uk, Atom syntax In-Reply-To: <1f2ed5cd0408260850a6def08@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040826153723.22538.qmail@web41203.mail.yahoo.com> <1f2ed5cd0408260850a6def08@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit PS. We could have moved directly past a lot of issues had we adopted some more of that second spec... On Thu, 26 Aug 2004 17:50:46 +0200, Danny Ayers wrote: > Heh - you beat me to it. > > +1. > > > > On Thu, 26 Aug 2004 08:37:23 -0700 (PDT), Dare Obasanjo wrote: > > > > --- Danny Ayers wrote: > > > > > > Having said all that, allow me to turn the argument > > > around a little. > > > Why should the the tag: scheme need to be > > > registered? If Atom's id > > > uses string comparison rather than rfc2396's > > > definition of equivalence > > > it's not a URI anyway. > > > > Why are people going around and around on this? There > > is precedent for this behavior in > > http://www.w3.org/TR/REC-xml-names/ and > > http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference > > > > Basically the two major W3C specs that utilize URIs as > > identifiers define character by character comparison > > and don't require canonicalization > > > > Can we just move past this issue, please? > > > > ===== > > THINGS TO DO IF I BECOME AN EVIL OVERLORD #25 > > No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot. > > > > > > __________________________________ > > Do you Yahoo!? > > Y! Messenger - Communicate in real time. Download now. > > http://messenger.yahoo.com > > > From owner-atom-syntax@mail.imc.org Thu Aug 26 12:07:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14519 for ; Thu, 26 Aug 2004 12:07:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFxKUN007345; Thu, 26 Aug 2004 08:59:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QFxKSA007344; Thu, 26 Aug 2004 08:59:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QFxIZD007328 for ; Thu, 26 Aug 2004 08:59:20 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 41011 invoked by uid 17064); 26 Aug 2004 15:59:21 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.128.186]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 26 Aug 2004 15:59:21 -0000 In-Reply-To: <20040826153723.22538.qmail@web41203.mail.yahoo.com> References: <20040826153723.22538.qmail@web41203.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Dare Obasanjo From: Henry Story Subject: Re: Follow the W3Cs Example (Re: URIs vs Strings) Date: Thu, 26 Aug 2004 17:59:16 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Aug 2004, at 17:37, Dare Obasanjo wrote: > > > --- Danny Ayers wrote: >> >> Having said all that, allow me to turn the argument >> around a little. >> Why should the the tag: scheme need to be >> registered? If Atom's id >> uses string comparison rather than rfc2396's >> definition of equivalence >> it's not a URI anyway. > > Why are people going around and around on this? There > is precedent for this behavior in > http://www.w3.org/TR/REC-xml-names/ and > http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference > > Basically the two major W3C specs that utilize URIs as > identifiers define character by character comparison > and don't require canonicalization > > Can we just move past this issue, please? Pretty cool. So why not just rewrite the spec to use urirefs? Then we have precedence on our side, the problem is solved, and the debate is ended. Henry From owner-atom-syntax@mail.imc.org Thu Aug 26 12:17:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15188 for ; Thu, 26 Aug 2004 12:17:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QG7VAi009214; Thu, 26 Aug 2004 09:07:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QG7VTc009213; Thu, 26 Aug 2004 09:07:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QG7UAu009204 for ; Thu, 26 Aug 2004 09:07:30 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 82809 invoked from network); 26 Aug 2004 16:07:30 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 26 Aug 2004 16:07:30 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412E0ACD.4080200@internetalchemy.org> Date: Thu, 26 Aug 2004 17:07:41 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> In-Reply-To: <14be96d3040826071922d4fd90@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26/08/2004 15:19, Mark Pilgrim wrote: > tag: URIs use a combination of a domain name + a date on which you > controlled that domain as the starting point for constructing a > globally unique ID. In the absence of a domain name, an email address > that you controlled on that date would also suffice. (This is > mentioned explicitly in the spec.) > > The usual suspects will now pounce on me and warn (correctly) that > tag: URIs are not a registered URI scheme. But that doesn't negate > the fact that it is relatively simple to create globally unique IDs. > All you need is something that is globally unique at a moment in time, > plus the moment in time. Both of these are readily available. The 'tag' scheme is problematic since it requires the minter of the URI to have authority over a domain name or expose their email address in every ID. The majority of publishers will not have their own domain (e.g. LiveJournal or Blogger) and will be forced to use their email address. The requirement to use a DNS name in the tag uri also places overhead on large organisations with multiple points of feed production. These would have to coordinate tag production. Not to mention the problems with the specification of email addresses. For example, it doesn't allow iand+atom@example.com Besides all these issues, I'm fond of the 'tag' schema and it certainly has uses for those interested enough to have their own domain. I don't think that includes the majority of potential Atom publishers though. Ian From owner-atom-syntax@mail.imc.org Thu Aug 26 12:18:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15273 for ; Thu, 26 Aug 2004 12:18:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGCQWL010156; Thu, 26 Aug 2004 09:12:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QGCQKO010155; Thu, 26 Aug 2004 09:12:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGCQWC010128 for ; Thu, 26 Aug 2004 09:12:26 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA28663 for ; Thu, 26 Aug 2004 09:12:24 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA15375 for ; Thu, 26 Aug 2004 09:12:23 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Thu, 26 Aug 2004 09:12:22 -0700 Received: from air-wunder.verity.com (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7QGCIlB004628 for ; Thu, 26 Aug 2004 09:12:21 -0700 (PDT) Date: Thu, 26 Aug 2004 09:12:24 -0700 From: Walter Underwood To: Atom-Syntax Subject: Re: PaceIdConstruct Message-ID: In-Reply-To: <412D8A67.3070608@gmx.de> References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <412D8A67.3070608@gmx.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Thursday, August 26, 2004 8:59 AM +0200 Julian Reschke wrote: > > Speaking of which - how do you prevent people from using both > > http://example.com > > and > > http://example.com:80 > > if you just require canonicalization? Both are canonical, ... Neither one is canonical. Add a trailing slash, according to this rule: For schemes that define an empty path to be equivalent to a path of "/", use "/". Post to the URI working group list, suggesting that they add default port elision to the canonicalization rules. I will post to the URI WG about the rules not being clear enough, since you missed that one. Please let me know whether you did read the rules, so I can let them know (privately is fine, this is off-topic for Atom). wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu Aug 26 12:34:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16522 for ; Thu, 26 Aug 2004 12:34:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGQbkq012363; Thu, 26 Aug 2004 09:26:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QGQbC7012362; Thu, 26 Aug 2004 09:26:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGQaVE012344 for ; Thu, 26 Aug 2004 09:26:36 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so338185rnk for ; Thu, 26 Aug 2004 09:26:33 -0700 (PDT) Received: by 10.38.102.54 with SMTP id z54mr2283702rnb; Thu, 26 Aug 2004 09:26:33 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Thu, 26 Aug 2004 09:26:33 -0700 (PDT) Message-ID: <14be96d30408260926c798363@mail.gmail.com> Date: Thu, 26 Aug 2004 12:26:33 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Ian Davis Subject: Re: URIs vs Strings Cc: Atom syntax In-Reply-To: <412E0ACD.4080200@internetalchemy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 17:07:41 +0100, Ian Davis wrote: > The 'tag' scheme is problematic since it requires the minter of the URI > to have authority over a domain name or expose their email address in > every ID. The majority of publishers will not have their own domain > (e.g. LiveJournal or Blogger) and will be forced to use their email > address. I'm pretty sure Blogger has their own domain. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu Aug 26 12:41:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17229 for ; Thu, 26 Aug 2004 12:41:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGVlp3013044; Thu, 26 Aug 2004 09:31:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QGVl0K013043; Thu, 26 Aug 2004 09:31:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGVkaG013036 for ; Thu, 26 Aug 2004 09:31:46 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7QGVnil017774 for ; Thu, 26 Aug 2004 10:31:49 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3200EHRB902I@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 26 Aug 2004 10:31:49 -0600 (MDT) Received: from [192.168.1.2] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I3200HCUB8ZOJ@mail.sun.net> for atom-syntax@imc.org; Thu, 26 Aug 2004 10:31:48 -0600 (MDT) Date: Thu, 26 Aug 2004 09:31:44 -0700 From: Tim Bray Subject: Re: Feeds MUST have alternate links? In-reply-to: <20040826145735.79336.qmail@web41206.mail.yahoo.com> To: Dare Obasanjo Cc: =?ISO-8859-1?Q?Asbj=F8rn=5FUlsberg?= , Norman Walsh , Sam Ruby , Atom-Syntax Message-id: <6B3D9FB4-F77D-11D8-A7D9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040826145735.79336.qmail@web41206.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 26, 2004, at 7:57 AM, Dare Obasanjo wrote: > For example, I'm > in the process of adding NNTP support to RSS Bandit. I > will archive USENET groups and RSS feeds in the same > format. If I choose Atom as this format what would you > suggest I use as the alternate link for the feed for > microsoft.public.dotnet.xml? > > Would 'news:microsoft.public.dotnet.xml' be an > acceptable value? Sounds plausible. Another possibility would be http://groups.google.com/groups?group=microsoft.public.dotnet.xml, er, well, the MSDN equivalent I guess :) -Tim From owner-atom-syntax@mail.imc.org Thu Aug 26 12:52:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17870 for ; Thu, 26 Aug 2004 12:52:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGYlGc013610; Thu, 26 Aug 2004 09:34:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QGYlmr013609; Thu, 26 Aug 2004 09:34:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QGYkUF013595 for ; Thu, 26 Aug 2004 09:34:46 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040826163444.17635.qmail@web41212.mail.yahoo.com> Received: from [67.160.81.108] by web41212.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 09:34:44 PDT Date: Thu, 26 Aug 2004 09:34:44 -0700 (PDT) From: Dare Obasanjo Subject: Re: Feeds MUST have alternate links? To: Tim Bray Cc: "Asbjørn_Ulsberg" , Norman Walsh , Sam Ruby , Atom-Syntax In-Reply-To: <6B3D9FB4-F77D-11D8-A7D9-000A95A51C9E@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Tim Bray wrote: > > If I choose Atom as this format what would > you > > suggest I use as the alternate link for the feed > for > > microsoft.public.dotnet.xml? > > > > Would 'news:microsoft.public.dotnet.xml' be an > > acceptable value? > > Sounds plausible. Another possibility would be > http://groups.google.com/groups?group=microsoft.public.dotnet.xml, > er, > well, the MSDN equivalent I guess :) -Tim Except neither of these indexes all news groups [especially not newsgroups within an intranet]. So that link would 404 at unexpected times. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 26 12:57:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18179 for ; Thu, 26 Aug 2004 12:57:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGnMk8015514; Thu, 26 Aug 2004 09:49:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QGnMoW015513; Thu, 26 Aug 2004 09:49:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QGnLvO015507 for ; Thu, 26 Aug 2004 09:49:21 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so219753rnb for ; Thu, 26 Aug 2004 09:49:21 -0700 (PDT) Received: by 10.38.206.56 with SMTP id d56mr418757rng; Thu, 26 Aug 2004 09:49:21 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 09:49:21 -0700 (PDT) Message-ID: <1f2ed5cd04082609491e48b80b@mail.gmail.com> Date: Thu, 26 Aug 2004 18:49:21 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: URIs vs Strings Cc: Mark Pilgrim , davep@dpawson.co.uk, Atom syntax In-Reply-To: <412DFD81.5000103@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> <412DFD81.5000103@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison-string Sure, individual Atom ids may be a URIs according to the spec. But unless the Atom identification system follows all of the requirements of the URI spec (including the other comparisons), then it would be inaccurate and misleading to say that Atom's identifiers are the same things as URIs. Cheers, Danny. From owner-atom-syntax@mail.imc.org Thu Aug 26 13:08:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19025 for ; Thu, 26 Aug 2004 13:08:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QH2B7w017137; Thu, 26 Aug 2004 10:02:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QH2B3k017136; Thu, 26 Aug 2004 10:02:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QH29YY017124 for ; Thu, 26 Aug 2004 10:02:10 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 4551 invoked by uid 65534); 26 Aug 2004 17:02:07 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.18]) (217.5.201.10) by mail.gmx.net (mp015) with SMTP; 26 Aug 2004 19:02:07 +0200 X-Authenticated: #1915285 Message-ID: <412E1788.2060806@gmx.de> Date: Thu, 26 Aug 2004 19:02:00 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: mint@franklinmint.fm, Mark Pilgrim , davep@dpawson.co.uk, Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> <412DFD81.5000103@franklinmint.fm> <1f2ed5cd04082609491e48b80b@mail.gmail.com> In-Reply-To: <1f2ed5cd04082609491e48b80b@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: >>http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison-string > > > Sure, individual Atom ids may be a URIs according to the spec. But > unless the Atom identification system follows all of the requirements > of the URI spec (including the other comparisons), then it would be These aren't "requirements". They are definitions of possible comparisons. Picking the simplest one is perfectly ok and doesn't make the IDs less URI-like. > inaccurate and misleading to say that Atom's identifiers are the same > things as URIs. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 13:11:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19544 for ; Thu, 26 Aug 2004 13:11:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QH4Nap017247; Thu, 26 Aug 2004 10:04:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QH4NoW017246; Thu, 26 Aug 2004 10:04:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QH4MW6017240 for ; Thu, 26 Aug 2004 10:04:22 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0Nfi-00046u-OW; Thu, 26 Aug 2004 17:04:22 +0000 Message-ID: <412E180E.2090403@franklinmint.fm> Date: Thu, 26 Aug 2004 13:04:14 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> <412DFD81.5000103@franklinmint.fm> <1f2ed5cd04082609491e48b80b@mail.gmail.com> In-Reply-To: <1f2ed5cd04082609491e48b80b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: >>http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison-string > > > Sure, individual Atom ids may be a URIs according to the spec. But > unless the Atom identification system follows all of the requirements > of the URI spec (including the other comparisons), then it would be > inaccurate and misleading to say that Atom's identifiers are the same > things as URIs. > The specification plainly states that different types of comparison are appropriate for different applications. It does not state that a failing equality test in section 6.2.1 means that application MUST proceed to step 6.2.2. BTW, Tim wrote this section of 2396bis. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 13:16:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20063 for ; Thu, 26 Aug 2004 13:16:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHAdFv018013; Thu, 26 Aug 2004 10:10:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHAdoP018012; Thu, 26 Aug 2004 10:10:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHAbE5018004 for ; Thu, 26 Aug 2004 10:10:38 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <14be96d3040826071922d4fd90@mail.gmail.com> References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> Date: Thu, 26 Aug 2004 10:10:27 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: URIs vs Strings Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:19 AM -0400 8/26/04, Mark Pilgrim wrote: >On Thu, 26 Aug 2004 06:43:07 +0100, Dave Pawson wrote: >> I still thinks its a valid question, >> " How can a blog writer find a globally unique string to identify his >> entry with?" >> >> Unless the writer owns a domain name, what do you think he or she will >> use when 'required' to produce a unique uri|l? > >tag: URIs use a combination of a domain name + a date on which you >controlled that domain as the starting point for constructing a >globally unique ID. In the absence of a domain name, an email address >that you controlled on that date would also suffice. (This is >mentioned explicitly in the spec.) > >The usual suspects will now pounce on me and warn (correctly) that >tag: URIs are not a registered URI scheme. We should not encourage use of unregistered URI schemes. > But that doesn't negate >the fact that it is relatively simple to create globally unique IDs. >All you need is something that is globally unique at a moment in time, >plus the moment in time. Both of these are readily available. Exactly. If the only thing you have control over on the Internet is a mail address, you can still make GUIDs based on valid URIs. is an easily-formed ID that is a valid (and even canonical) URI. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 26 13:24:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20937 for ; Thu, 26 Aug 2004 13:24:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QH9bs6017936; Thu, 26 Aug 2004 10:09:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QH9bLg017935; Thu, 26 Aug 2004 10:09:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QH9aSM017929 for ; Thu, 26 Aug 2004 10:09:36 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 47925 invoked from network); 26 Aug 2004 17:09:36 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 26 Aug 2004 17:09:36 -0000 Received: from 194.203.191.188 ([194.203.191.188]) by webmail.djpowell.net (IMP) with HTTP for ; Thu, 26 Aug 2004 18:09:36 +0100 Message-ID: <1093540176.412e19505c123@webmail.djpowell.net> Date: Thu, 26 Aug 2004 18:09:36 +0100 From: David Powell To: Danny Ayers Cc: Henry Story , Atom Syntax , Mark Pilgrim Subject: Re: URIrefs vs URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608487ae082d6@mail.gmail.com> In-Reply-To: <1f2ed5cd04082608487ae082d6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 194.203.191.188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Danny Ayers : > 2. Should Atom use URIrefs for IDs? It depends on whether we reference 2396classic or 2396bis. I wrote PaceUriReferences[1] a few weeks ago. It basically proposes replacing all use of the term "URI" with "URI reference", and then clarifies that atom:id should be an "absolute URI reference". RFC2396bis changes things though, because fragment is now part of "URI", rather than being relegated to being part of "URI reference", so I guess "absolute URI reference" and "URI" are the same thing under the newer draft? > 1. Should http://example.org/foo#bar be considered the same id as > http://example.org/foo#wub ? No, because they are different absoulute-URIRefs / URIs. HTML also seems to use the term URI everywhere when it would be more accurate to use URI reference. [2][3] [1] http://www.intertwingly.net/wiki/pie/PaceUriReferences [2] http://www.w3.org/TR/html4/struct/links.html#h-12.1 [3] http://www.w3.org/TR/html4/types.html#type-uri -- Dave From owner-atom-syntax@mail.imc.org Thu Aug 26 13:32:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21617 for ; Thu, 26 Aug 2004 13:32:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHNpRC018976; Thu, 26 Aug 2004 10:23:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHNpXP018975; Thu, 26 Aug 2004 10:23:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHNoFE018969 for ; Thu, 26 Aug 2004 10:23:50 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0NyZ-0007UD-32 for atom-syntax@imc.org; Thu, 26 Aug 2004 17:23:51 +0000 Message-ID: <412E1CA2.9030404@franklinmint.fm> Date: Thu, 26 Aug 2004 13:23:46 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Close PaceErrVerb Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Now that PaceServiceError uses its own HTTP method, the only substantive differences are: * payload * whether error requests must be sent to the requestURI PaceServiceError could easily be adjusted to accommodate either of these requirements, and is more thoroughly specified in almost every area they have in common. Unless someone steps forward offering to complete PaceErrVerb, we should close it. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 13:37:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22037 for ; Thu, 26 Aug 2004 13:37:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHTK29019234; Thu, 26 Aug 2004 10:29:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHTKuc019233; Thu, 26 Aug 2004 10:29:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHTIXH019222 for ; Thu, 26 Aug 2004 10:29:19 -0700 (PDT) (envelope-from adrian.cuthbert@bigfoot.com) Received: from HOME ([81.104.212.8]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20040826172940.YVVD23525.mta07-svc.ntlworld.com@HOME> for ; Thu, 26 Aug 2004 18:29:40 +0100 From: "Adrian Cuthbert" To: Subject: Embedding microcontent in an Atom feed Date: Thu, 26 Aug 2004 18:30:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I am new to this mailing list so please forgive me if the question is not pitched at the correct level. I have a question about embedding multiple bits of information (each of which can be represented in XML and has its own mime-type) in a single Atom entry. An example might be that I have an entry describing some up-coming exhibition and I also have a number of dates for it. I would like to encode the descriptive part as XHTML and the dates in some (TBD) XML encoding, lets postulate a text/vcalendar+xml. This scenario arises from an interest in building more intelligent aggregators, or maybe plug-ins to augment existing aggregators. For example the aggregator might be able extract particular mime-types from an entry and present them in a different way from a standard 'news' aggregator. For example 'event' information might be presented in a calendar-like view. My understanding of the Atom Syndication Format is that entries may have multiple content elements, each with its own @type. If a content element has a @type of 'multipart/alternative' then there can only be a single level of nesting. Atom consumers (like my hypothetical aggregator) SHOULD look at all alternative content elements and determine which one is most suitable, based on which @type and @mode the consumer supports, and preferences specified by the end user (if any). Consumers SHOULD NOT render more than one content alternative. Is there a real difference between having multiple content elements each with its own non-multipart @type and haveing a single content element with a multipart @type and a single level of nesting? If there is no difference then presumably the restrictions on consumers that apply to content elements with a multipart @type also apply to consumers of entries with multiple content elements, ie they should look at them all but only render one. Does anyone have a scenario where this is employed? A possible example might be a consumer that is delivering to a mobile device with limited capabilities. Under such circumstances content of @type 'text/plain' might win out over content with @type 'application/xhtml+xml'. This would seem to indicate that there is no sensible way to include content with @type 'text/vcalendar+xml' and @type 'application/xhtml+xml' in the same entry, since I cannot see how a consumer could be expected to choose between the two. Of course an alternate approach would be to use link elements to point to the 'event' information and use @rel to identify special types of information to the consumer. However the need to publish what is conceptually one entry in multiple places does not seem attractive. Indeed any ability to consume different types of what I would call 'microcontent' needs to be matched by an ability to easily author and publish such content. Much blogging software doesn't provide for a way to publish multiple content elements in an entry. Maybe I approaching this the wrong way. My interest is in Atom's extensibility, specifically an ability to publish entries which contain specialist types of microcontent and then have Atom consumers able to extract that microcontent and present it in a way best suited to its specialist nature. Can anybody point me in the right direction? Regards Adrian http://adriancuthbert.blogspot.com/2004/08/questions-about-embedding-microco ntent.html From owner-atom-syntax@mail.imc.org Thu Aug 26 14:06:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24084 for ; Thu, 26 Aug 2004 14:06:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHvBGW021615; Thu, 26 Aug 2004 10:57:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QHvBZk021614; Thu, 26 Aug 2004 10:57:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QHvAIn021607 for ; Thu, 26 Aug 2004 10:57:10 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0OUp-0004Hu-7l; Thu, 26 Aug 2004 17:57:11 +0000 Message-ID: <412E2472.3060700@franklinmint.fm> Date: Thu, 26 Aug 2004 13:57:06 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Atom WG Subject: Re: PaceItemLicense References: <14be96d3040824080140cc3f93@mail.gmail.com> In-Reply-To: <14be96d3040824080140cc3f93@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > -1. We already have entry-level element for > human-readable copyright information. Precisely zero of our early > adopters have been heard clamoring for machine-readable licensing > information, so IMO it doesn't belong in the core. Let's shunt this > one to an extension. -1 as well Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 14:13:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24666 for ; Thu, 26 Aug 2004 14:13:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QI5aL5022677; Thu, 26 Aug 2004 11:05:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QI5aW6022676; Thu, 26 Aug 2004 11:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QI5a8j022669 for ; Thu, 26 Aug 2004 11:05:36 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 77060 invoked from network); 26 Aug 2004 18:05:38 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 26 Aug 2004 18:05:38 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412E267D.4050109@internetalchemy.org> Date: Thu, 26 Aug 2004 19:05:49 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> In-Reply-To: <14be96d30408260926c798363@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26/08/2004 17:26, Mark Pilgrim wrote: > On Thu, 26 Aug 2004 17:07:41 +0100, Ian Davis wrote: > >>The 'tag' scheme is problematic since it requires the minter of the URI >>to have authority over a domain name or expose their email address in >>every ID. The majority of publishers will not have their own domain >>(e.g. LiveJournal or Blogger) and will be forced to use their email >>address. > > > I'm pretty sure Blogger has their own domain. > I hope so. I'm pretty sure LiveJournal does too. I'm missing the subtle point you're making. I'm pretty sure you aren't conflating the publishers of content with the tool providers. Can you clarify what you meant. Ian From owner-atom-syntax@mail.imc.org Thu Aug 26 14:23:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25399 for ; Thu, 26 Aug 2004 14:23:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIFNXr023702; Thu, 26 Aug 2004 11:15:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QIFN3G023701; Thu, 26 Aug 2004 11:15:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIFMdU023695 for ; Thu, 26 Aug 2004 11:15:22 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0OmQ-00070J-GO; Thu, 26 Aug 2004 18:15:22 +0000 Message-ID: <412E28B5.6030507@franklinmint.fm> Date: Thu, 26 Aug 2004 14:15:17 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Davis CC: Mark Pilgrim , Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> In-Reply-To: <412E267D.4050109@internetalchemy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > > On 26/08/2004 17:26, Mark Pilgrim wrote: > >> On Thu, 26 Aug 2004 17:07:41 +0100, Ian Davis >> wrote: >> >>> The 'tag' scheme is problematic since it requires the minter of the URI >>> to have authority over a domain name or expose their email address in >>> every ID. The majority of publishers will not have their own domain >>> (e.g. LiveJournal or Blogger) and will be forced to use their email >>> address. >> >> >> >> I'm pretty sure Blogger has their own domain. >> > I hope so. I'm pretty sure LiveJournal does too. I'm missing the subtle > point you're making. I'm pretty sure you aren't conflating the > publishers of content with the tool providers. Can you clarify what you > meant. These services take care of id generation for their users. Example feed: http://www.livejournal.com/users/jwz/data/atom Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 14:32:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25951 for ; Thu, 26 Aug 2004 14:32:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIIGRm024124; Thu, 26 Aug 2004 11:18:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QIIGEP024123; Thu, 26 Aug 2004 11:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIIFvB024117 for ; Thu, 26 Aug 2004 11:18:15 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0OpD-0007fe-MR; Thu, 26 Aug 2004 18:18:15 +0000 Message-ID: <412E2962.4030708@franklinmint.fm> Date: Thu, 26 Aug 2004 14:18:10 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Atom WG Subject: Re: PaceReduceMustMay References: <14be96d304082408125a4e04db@mail.gmail.com> In-Reply-To: <14be96d304082408125a4e04db@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > This "Pace" only lists two vague proposals: > > """ > 1. First pass: de-emphasize RFC2119 imperatives where used for content > models or markup syntax. > 2. Second pass: rephrase for easier reading using a less formal tone. > """ > > I'm all for #1, using RFC 2119 terminology correctly, but this Pace is > utterly lacking in specifics. What do we use? DTD, XSD, RNG, Schematron... Otherwise, it sounds good as long as the Notational Conventions section makes it clear that the schema is not normative. Ken has reminded us that: "The decision factor for using a schema language as a *notation* is lower than the decision factor for having a normative schema. WebDAV, for example, uses DTD notation for speccing element models but does not have a normative DTD (since that would restrict Namespace usage and enforce insignificant element ordering)." > > I'm against #2. > There's no concrete direction here. I promise to read everything out loud before I submit it ;) Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 14:45:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26929 for ; Thu, 26 Aug 2004 14:45:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIa1P3026207; Thu, 26 Aug 2004 11:36:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QIa1c1026206; Thu, 26 Aug 2004 11:36:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIa1Ix026194 for ; Thu, 26 Aug 2004 11:36:01 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so225825rnb for ; Thu, 26 Aug 2004 11:35:59 -0700 (PDT) Received: by 10.38.206.56 with SMTP id d56mr470054rng; Thu, 26 Aug 2004 11:35:59 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 11:35:59 -0700 (PDT) Message-ID: <1f2ed5cd0408261135578dcfdd@mail.gmail.com> Date: Thu, 26 Aug 2004 20:35:59 +0200 From: Danny Ayers Reply-To: Danny Ayers To: David Powell Subject: Re: URIrefs vs URIs vs Strings Cc: Henry Story , Atom Syntax , Mark Pilgrim In-Reply-To: <1093540176.412e19505c123@webmail.djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608487ae082d6@mail.gmail.com> <1093540176.412e19505c123@webmail.djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 18:09:36 +0100, David Powell wrote: > Quoting Danny Ayers : > > > 2. Should Atom use URIrefs for IDs? > > It depends on whether we reference 2396classic or 2396bis. > > I wrote PaceUriReferences[1] a few weeks ago. It basically proposes replacing > all use of the term "URI" with "URI reference", and then clarifies that atom:id > should be an "absolute URI reference". My apologies, I completely missed that one. > RFC2396bis changes things though, because fragment is now part of > "URI", rather than being relegated to being part of "URI reference", so I guess > "absolute URI reference" and "URI" are the same thing under the newer draft? > > > > 1. Should http://example.org/foo#bar be considered the same id as > > http://example.org/foo#wub ? > > No, because they are different absoulute-URIRefs / URIs. > HTML also seems to use the term URI everywhere when it would be more accurate to > use URI reference. [2][3] Ok. I'm not sure of IETF processes, but given that RFC2396bis hasn't yet been approved, presumably for now we'll have to reference 'classic' and call the IDs URIrefs - does that sound about right? But for the future this does lead back to the question of string comparisons... There does seem to be a conflict between URI refs in RFC2396bis and those of URI refs in RDF/XML namespaces. Cheers, Danny. From owner-atom-syntax@mail.imc.org Thu Aug 26 15:03:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27636 for ; Thu, 26 Aug 2004 15:03:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIs46V027949; Thu, 26 Aug 2004 11:54:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QIs4M9027948; Thu, 26 Aug 2004 11:54:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QIs4YM027942 for ; Thu, 26 Aug 2004 11:54:04 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0PNr-0006KP-Ku; Thu, 26 Aug 2004 18:54:03 +0000 Message-ID: <412E31C6.5090305@franklinmint.fm> Date: Thu, 26 Aug 2004 14:53:58 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: David Powell , Henry Story , Atom Syntax , Mark Pilgrim Subject: Re: URIrefs vs URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608487ae082d6@mail.gmail.com> <1093540176.412e19505c123@webmail.djpowell.net> <1f2ed5cd0408261135578dcfdd@mail.gmail.com> In-Reply-To: <1f2ed5cd0408261135578dcfdd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > > Ok. I'm not sure of IETF processes, but given that RFC2396bis hasn't > yet been approved, presumably for now we'll have to reference > 'classic' and call the IDs URIrefs - does that sound about right? > We've covered this issue in the past[0]. Paul stated that the chairs will examine this issue "later in the baking process". I am not implying that everyone should read and remember every message to atom-syntax. I have every message printed out and I wear a tinfoil hat when I am looking for an old message. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg06447.html From owner-atom-syntax@mail.imc.org Thu Aug 26 15:15:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29221 for ; Thu, 26 Aug 2004 15:15:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QJ84NM028932; Thu, 26 Aug 2004 12:08:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QJ84QH028931; Thu, 26 Aug 2004 12:08:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QJ84rg028925 for ; Thu, 26 Aug 2004 12:08:04 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so251882rnb for ; Thu, 26 Aug 2004 12:08:07 -0700 (PDT) Received: by 10.38.8.46 with SMTP id 46mr2828824rnh; Thu, 26 Aug 2004 12:08:07 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Thu, 26 Aug 2004 12:08:07 -0700 (PDT) Message-ID: <1f2ed5cd040826120832d56fc7@mail.gmail.com> Date: Thu, 26 Aug 2004 21:08:07 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: URIs vs Strings Cc: Atom syntax In-Reply-To: <412E180E.2090403@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> <412DFD81.5000103@franklinmint.fm> <1f2ed5cd04082609491e48b80b@mail.gmail.com> <412E180E.2090403@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 13:04:14 -0400, Robert Sayre wrote: > > > Danny Ayers wrote: > > >>http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison-string > > > > > > Sure, individual Atom ids may be a URIs according to the spec. But > > unless the Atom identification system follows all of the requirements > > of the URI spec (including the other comparisons), then it would be > > inaccurate and misleading to say that Atom's identifiers are the same > > things as URIs. > > > > The specification plainly states that different types of comparison are > appropriate for different applications. It does not state that a failing > equality test in section 6.2.1 means that application MUST proceed to > step 6.2.2. I think we're at cross-purposes here a little, (possibly still with disagreement ;-) - I've not been very clear. Let me try putting it another way. Ok, assume Atom IDs use URIs but with string comparison rather than the 'ladder'. Now Atom isn't an application in the sense used above, it's a specification to which applications can be built. As such I would suggest that it's inaccurate and misleading to say that Atom specifies its identification as URIs because applications built to support the Atom spec may behave differently to those built to the URI spec. An application using URIs may say http://example.org is the same as http://EXAMPLE.org. An application using Atom's idenification system would say they're different. Cheers, Danny. > BTW, Tim wrote this section of 2396bis. > > Robert Sayre > From owner-atom-syntax@mail.imc.org Thu Aug 26 15:39:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01102 for ; Thu, 26 Aug 2004 15:39:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QJWgxD031712; Thu, 26 Aug 2004 12:32:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QJWgOU031711; Thu, 26 Aug 2004 12:32:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QJWdYU031704 for ; Thu, 26 Aug 2004 12:32:41 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0PzD-00059c-76; Thu, 26 Aug 2004 19:32:40 +0000 Message-ID: <412E3AD2.6050009@franklinmint.fm> Date: Thu, 26 Aug 2004 15:32:34 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> <412DFD81.5000103@franklinmint.fm> <1f2ed5cd04082609491e48b80b@mail.gmail.com> <412E180E.2090403@franklinmint.fm> <1f2ed5cd040826120832d56fc7@mail.gmail.com> In-Reply-To: <1f2ed5cd040826120832d56fc7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > On Thu, 26 Aug 2004 13:04:14 -0400, Robert Sayre wrote: > As such I would suggest that it's inaccurate and misleading to say > that Atom specifies its identification as URIs because applications > built to support the Atom spec may behave differently to those built > to the URI spec. An application using URIs may say http://example.org > is the same as http://EXAMPLE.org. An application using Atom's > idenification system would say they're different. Once again, section 6 specifically states that that false negatives will happen. It's not inaccurate or misleading in any sense. If you disagree, propose alternate spec language and we can continue this oh-so-productive debate. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 16:13:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06417 for ; Thu, 26 Aug 2004 16:13:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QK23iv033890; Thu, 26 Aug 2004 13:02:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QK23hI033889; Thu, 26 Aug 2004 13:02:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QK22SJ033883 for ; Thu, 26 Aug 2004 13:02:02 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0QRc-0002SJ-LQ; Thu, 26 Aug 2004 20:02:00 +0000 Message-ID: <412E41B2.7090703@franklinmint.fm> Date: Thu, 26 Aug 2004 16:01:54 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Atom WG Subject: Re: PaceEquivalents References: <14be96d3040824075565ef4da1@mail.gmail.com> In-Reply-To: <14be96d3040824075565ef4da1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > Several of the "equivalencies" listed in PaceEquivalents have been > hotly contested in recent weeks, for example all of the date > equivalencies. I think we should mark this as "revisit". In principle, I'm fine with a non-normative appendix stating this stuff. The Pace author has promised to refactor the proposal to be an appendix. I'd rather not revisit this issue until we're close to done. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 16:19:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07400 for ; Thu, 26 Aug 2004 16:19:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QK9Mch034743; Thu, 26 Aug 2004 13:09:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QK9Mvf034742; Thu, 26 Aug 2004 13:09:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QK9LrD034736 for ; Thu, 26 Aug 2004 13:09:21 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 79387 invoked from network); 26 Aug 2004 20:09:22 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 26 Aug 2004 20:09:22 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412E437C.9080501@internetalchemy.org> Date: Thu, 26 Aug 2004 21:09:32 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Mark Pilgrim , Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> In-Reply-To: <412E28B5.6030507@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26/08/2004 19:15, Robert Sayre wrote: > > These services take care of id generation for their users. Example feed: > > http://www.livejournal.com/users/jwz/data/atom Understood , but blogger publishes to a site via FTP so it's a tool provider with data storage like a web version of CityDesk or Radio Userland. Would those tools be expected to generate tags based on the citydesk or userland domains? What happens if the tool developer goes bust, gets acquired or changes its domain. Old versions of the tool would continue to produce tags based on domains that are not owned by the tool developer with potential conflicts. Surely the tag domains would have to be based on the publisher's information, not the tool provider's. This means that the large number of people without their own domain will be required to expose their email addresses in every entry they publish. Rather than continually pushing unsuitable URI schemes we ought to accept that the web seems to work just dandy with generic URIs. Let's just do as Dare suggests: character by character comparison without require canonicalization. I think it's pretty unlikely that clients are going to be directly comparing atom IDs anyway. It seems pretty inefficient to store 100+ bytes for *every* entry *ever* retrieved by the client. Does anyone believe that any client is going to directly compare new 100+ byte IDs against the list of 10,000+ already seen? Most clients will stick them into a database and index them, so the comparison is made against the hash of the ID instead of the original bytes. Ian Ian From owner-atom-syntax@mail.imc.org Thu Aug 26 16:19:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07559 for ; Thu, 26 Aug 2004 16:19:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QK9l3O034777; Thu, 26 Aug 2004 13:09:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QK9l3J034776; Thu, 26 Aug 2004 13:09:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QK9kwT034769 for ; Thu, 26 Aug 2004 13:09:46 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 79717 invoked from network); 26 Aug 2004 20:09:49 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 26 Aug 2004 20:09:49 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412E4398.7040008@internetalchemy.org> Date: Thu, 26 Aug 2004 21:10:00 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: ID - wrong solution to the problem? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It seems to me that there's a lot of energy going into solving a relatively minor issue: that of duplicate entries. There may be other ways to solve the problem. 1. Some way to declare that a feed is an aggregate or filtered version of other feeds? List the other feeds so clients can check if the user is subcribed to any of those. If so, duplicates should be expected. These can be detected by comparing links, titles and descriptions as is done in RSS at the moment. The client has some hints about where to look so the scale of the problem is reduced. 2. A way to declare that the feed will never contain duplicates. This can be true in many situations - most weblogs dont't repeat themselves and lots of publishing tools can be configured not to show an entry in the feed again if it has just been edited. This would also be suitable for event driven feeds such as CVS checkins or log files. In fact I believe there are many many feeds that can guarantee not to repeat entries, barring system errors. 3. A way to include a version number in an entry. Clients could decide not to show an entry if it's not the first version. Publishers would change the version number if they change the content of the entry. Ian From owner-atom-syntax@mail.imc.org Thu Aug 26 16:38:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09657 for ; Thu, 26 Aug 2004 16:38:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QKVtre036714; Thu, 26 Aug 2004 13:31:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QKVt49036713; Thu, 26 Aug 2004 13:31:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QKVsre036707 for ; Thu, 26 Aug 2004 13:31:54 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0QuY-0000Rn-QA; Thu, 26 Aug 2004 20:31:54 +0000 Message-ID: <412E48B6.3020603@franklinmint.fm> Date: Thu, 26 Aug 2004 16:31:50 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Davis CC: Mark Pilgrim , Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> In-Reply-To: <412E437C.9080501@internetalchemy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > > Rather than continually pushing unsuitable URI schemes we ought to > accept that the web seems to work just dandy with generic URIs. Let's > just do as Dare suggests: character by character comparison > without require canonicalization. > Aha! We're not actually arguing. I don't know diddly about what makes a URI scheme suitable, but I do know what the current consensus is: http://www.imc.org/atom-syntax/mail-archive/msg08572.html and, shock of shocks, it's character-by-character comparison without requiring canonicalization. Just like XML Namespaces. I think we're on our twentieth lap here. The only disagreement is from Mark (anyone else?) on c14n. Maybe Mark can let us move forward with this draft. Then he can propose PaceRequireCanonicalization later on, against concrete spec text. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 16:54:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10903 for ; Thu, 26 Aug 2004 16:54:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QKh47a037462; Thu, 26 Aug 2004 13:43:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QKh4VH037461; Thu, 26 Aug 2004 13:43:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QKh2G4037449 for ; Thu, 26 Aug 2004 13:43:03 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 6780 invoked by uid 65534); 26 Aug 2004 20:42:57 -0000 Received: from pD9E51DCD.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.29.205) by mail.gmx.net (mp004) with SMTP; 26 Aug 2004 22:42:57 +0200 X-Authenticated: #1915285 Message-ID: <412E4B4E.1070602@gmx.de> Date: Thu, 26 Aug 2004 22:42:54 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: mint@franklinmint.fm, Atom syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <1f2ed5cd04082608003e7c3ce1@mail.gmail.com> <412DFD81.5000103@franklinmint.fm> <1f2ed5cd04082609491e48b80b@mail.gmail.com> <412E180E.2090403@franklinmint.fm> <1f2ed5cd040826120832d56fc7@mail.gmail.com> In-Reply-To: <1f2ed5cd040826120832d56fc7@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > I think we're at cross-purposes here a little, (possibly still with > disagreement ;-) - I've not been very clear. Let me try putting it > another way. Ok, assume Atom IDs use URIs but with string comparison > rather than the 'ladder'. Now Atom isn't an application in the sense There is no way a spec could require comparison using the full "ladder", unless it restricts itself to a finite set of known schemes for which scheme-based and protocol-based normalization are actually *defined*. In general, they may not be defined at all. > used above, it's a specification to which applications can be built. How is that relevant? And what definition of "application" are you using here? > As such I would suggest that it's inaccurate and misleading to say > that Atom specifies its identification as URIs because applications > built to support the Atom spec may behave differently to those built > to the URI spec. An application using URIs may say http://example.org > is the same as http://EXAMPLE.org. An application using Atom's > idenification system would say they're different. So? Again: - there are many ways to compare URIs, - some of which are scheme-dependant Different applications may pick different comparison methods (or none at all), but that doesn't change the fact that all of them are using URIs just the way they are defined in RFC2396(bis). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Aug 26 17:17:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13453 for ; Thu, 26 Aug 2004 17:17:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QL6maJ039592; Thu, 26 Aug 2004 14:06:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QL6miG039591; Thu, 26 Aug 2004 14:06:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QL6m82039579 for ; Thu, 26 Aug 2004 14:06:48 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc12) with SMTP id <20040826210646014007q34oe>; Thu, 26 Aug 2004 21:06:47 +0000 Date: Thu, 26 Aug 2004 15:06:45 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: URIs vs Strings From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 26, 2004, at 02:09 PM, Ian Davis wrote: > On 26/08/2004 19:15, Robert Sayre wrote: >> These services take care of id generation for their users. Example >> feed: >> http://www.livejournal.com/users/jwz/data/atom > > Understood , but blogger publishes to a site via FTP so it's a tool > provider with data storage like a web version of CityDesk or Radio > Userland. Would those tools be expected to generate tags based on the > citydesk or userland domains? What happens if the tool developer goes > bust, gets acquired or changes its domain. Old versions of the tool > would continue to produce tags based on domains that are not owned by > the tool developer with potential conflicts. A tool like Blogger could safely mint IDs using its own domain name -- for example http://www.blogger.com//2004/8/26/1 -- without fear of collisions between blogs. If the domain name changes, the domain in new IDs would change, and the old one's would remain as there were. Or they could use the domain name/path to which the blog is being FTPd. Tools that are hosted on the client's server should use the client's domain. They should have the ability to "remember" (in any of a variety of ways) the correct IDs for old entries, even if the domain on which the system is hosted changes. > Surely the tag domains would have to be based on the publisher's > information, not the tool provider's. This means that the large number > of people without their own domain will be required to expose their > email addresses in every entry they publish. Here's a thought: use a hash of your email address instead of the address itself. I'd think that even blogs without domains all to themselves probably have their own unique base path, for example http://www.somebloghost.com/myblog/ vs. http://www.somebloghost.com/yourblog/. If the ID includes that base path, the date, and something to distinguish between entries posted on the same date, for example, there shouldn't be a problem. From owner-atom-syntax@mail.imc.org Thu Aug 26 17:27:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14252 for ; Thu, 26 Aug 2004 17:27:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLHgpq040517; Thu, 26 Aug 2004 14:17:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QLHgG7040516; Thu, 26 Aug 2004 14:17:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLHg5S040504 for ; Thu, 26 Aug 2004 14:17:42 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <2004082621174101300rgl6je>; Thu, 26 Aug 2004 21:17:41 +0000 Date: Thu, 26 Aug 2004 15:17:39 -0600 Subject: Re: ID - wrong solution to the problem? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <412E4398.7040008@internetalchemy.org> Message-Id: <5C617A5A-F7A5-11D8-ABD6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 26, 2004, at 02:10 PM, Ian Davis wrote: > It seems to me that there's a lot of energy going into solving a > relatively minor issue: that of duplicate entries. There may be other > ways to solve the problem. While it's good to think out of the box, this sounds like a lot more trouble than minting unique IDs. > 1. Some way to declare that a feed is an aggregate or filtered version > of other feeds? List the other feeds so clients can check if the user > is subcribed to any of those. If so, duplicates should be expected. > These can be detected by comparing links, titles and descriptions as > is done in RSS at the moment. The client has some hints about where to > look so the scale of the problem is reduced. Aside form this being a lot more work and more prone to error, what do you do if a feed is an aggregate or filtered version of a number of aggregate or filtered feeds? You could get to the point where the list of source feeds is longer than the feed itself. > 2. A way to declare that the feed will never contain duplicates. This > can be true in many situations - most weblogs dont't repeat themselves > and lots of publishing tools can be configured not to show an entry in > the feed again if it has just been edited. This would also be suitable > for event driven feeds such as CVS checkins or log files. In fact I > believe there are many many feeds that can guarantee not to repeat > entries, barring system errors. So what happens if you post an entry, and then before it has made its way off the end of the feed, you edit it? Do you leave the data in the feed as originally posted? Or do you modify the data in the feed? If you do, how should the fact that it's the same entry be detected? If comparing titles, links, and descriptions were fool-proof, IDs may never have been suggested at all. > 3. A way to include a version number in an entry. Clients could decide > not to show an entry if it's not the first version. Publishers would > change the version number if they change the content of the entry. What if the first version of the entry was posted and then modified before you saw it? You'd miss it completely. From owner-atom-syntax@mail.imc.org Thu Aug 26 17:34:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14628 for ; Thu, 26 Aug 2004 17:34:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLPMnK041389; Thu, 26 Aug 2004 14:25:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QLPMqR041388; Thu, 26 Aug 2004 14:25:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLPLq5041382 for ; Thu, 26 Aug 2004 14:25:21 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7QLPPmL024573; Thu, 26 Aug 2004 14:25:25 -0700 (PDT) Received: from [17.255.104.98] ([17.255.104.98]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i7QLP5M0013597; Thu, 26 Aug 2004 14:25:11 -0700 (PDT) In-Reply-To: <1f2ed5cd0408252339734dbd92@mail.gmail.com> References: <20040825182036.83573.qmail@web41202.mail.yahoo.com> <1f2ed5cd0408251153319d3d9c@mail.gmail.com> <41D37C34-F707-11D8-8440-000A95DC3D90@mac.com> <1f2ed5cd0408252339734dbd92@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--715808423; protocol="application/pkcs7-signature" Message-Id: <67C6B637-F7A6-11D8-8440-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceLinkRelMechanism Date: Thu, 26 Aug 2004 14:25:07 -0700 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3--715808423 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 25 Aug 2004, at 11:39 pm, Danny Ayers wrote: > No it hasn't, though you're welcome to try. > You get disambiguation because because the structure is clearly > defined unlike adding arbitrary namespaced elements/attributes > anywhere. It allows code reuse because the same subsystem for > dispatching behaviour from core elements can be reused > to handle dispatching for other rel values. else if (element.name=="link") { href=element.attr("href") rel=element.attr("rel") if (rel=="alternate") { alternate=href } else if (rel=="related") { related=href } } else if (element.name="...") { vs else if (element.name=="alternate") { alternate=element.attr("href") } else if (element=="related") { related=element.attr("href") } else if (element.name=="...") { Okay, so mine (the latter) repeats the attr("href"), which we haven't in yours (though it'd be easy enough to not repeat it). This is all the code reuse you get, because after that you have to do semantic-specific processing. That's why I say the benefits are minimal. > I honestly can't see why you have a problem with the notion of using a > common XML construct for a common range of data structures encountered > in syndication feeds. I have a common with using the element name as a type identifier. You can reuse the same construct if you like. Graham --Apple-Mail-3--715808423 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI2MjEyNTA4WjAjBgkqhkiG9w0BCQQxFgQUar3Z/df4YLe3FqZFng+Y438p n0wweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAFlyb7cPKVvrvJmeAAHiajG8R +7sask03aOa1Z5DpcJdshlR60qlAzjuNulyB5nf5mjagTpRfXxsCkaFBALfW0DxXdx1Y3HhnkwU2 w0RhKOTDfN1GJBLQ3Ij30nnIB1fWMlxJg6rdCNs41S9r5j2boOillRL1VvpLTZNkeEi8mjoRY0mr kNUo8gvKJGIM+IkOXtA9xuRdWYbOx8As5XgUhU2/bPD9UyRKFpCBr+zHathWFsUDzkPfhvughH33 NwQQ0s9BVpXj+jw4KiIWDB51+rQUZSKxBu17l/aTeVmkeW1HiB3HathoavDDzxQ73iTiH7RcE918 GQ5fsa0HK4ZJxwAAAAAAAA== --Apple-Mail-3--715808423-- From owner-atom-syntax@mail.imc.org Thu Aug 26 18:01:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16537 for ; Thu, 26 Aug 2004 18:01:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLsOEs043897; Thu, 26 Aug 2004 14:54:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QLsOwJ043896; Thu, 26 Aug 2004 14:54:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QLsNIP043886 for ; Thu, 26 Aug 2004 14:54:23 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040826215423.5241.qmail@web41203.mail.yahoo.com> Received: from [207.46.238.146] by web41203.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 14:54:23 PDT Date: Thu, 26 Aug 2004 14:54:23 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceLinkRelMechanism To: Graham , Danny Ayers Cc: Atom Syntax In-Reply-To: <67C6B637-F7A6-11D8-8440-000A95DC3D90@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: +1 --- Graham wrote: > On 25 Aug 2004, at 11:39 pm, Danny Ayers wrote: > > > No it hasn't, though you're welcome to try. > > You get disambiguation because because the > structure is clearly > > defined unlike adding arbitrary namespaced > elements/attributes > > anywhere. It allows code reuse because the same > subsystem for > > dispatching behaviour from core > elements can be reused > > to handle dispatching for other rel values. > > else if (element.name=="link") { > href=element.attr("href") > rel=element.attr("rel") > > if (rel=="alternate") { > alternate=href > } else if (rel=="related") { > related=href > } > } else if (element.name="...") { > > vs > > else if (element.name=="alternate") { > alternate=element.attr("href") > } else if (element=="related") { > related=element.attr("href") > } else if (element.name=="...") { > > Okay, so mine (the latter) repeats the attr("href"), > which we haven't > in yours (though it'd be easy enough to not repeat > it). This is all the > code reuse you get, because after that you have to > do semantic-specific > processing. That's why I say the benefits are > minimal. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 26 18:05:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16906 for ; Thu, 26 Aug 2004 18:05:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLwxZc044139; Thu, 26 Aug 2004 14:58:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QLwxC0044138; Thu, 26 Aug 2004 14:58:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QLwwnX044126 for ; Thu, 26 Aug 2004 14:58:59 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc12) with SMTP id <2004082621585801200p18lme>; Thu, 26 Aug 2004 21:58:58 +0000 Date: Thu, 26 Aug 2004 15:58:56 -0600 Subject: Re: PaceLinkRelMechanism Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <67C6B637-F7A6-11D8-8440-000A95DC3D90@mac.com> Message-Id: <20C7718B-F7AB-11D8-ABD6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 26, 2004, at 03:25 PM, Graham wrote: > On 25 Aug 2004, at 11:39 pm, Danny Ayers wrote: >> No it hasn't, though you're welcome to try. >> You get disambiguation because because the structure is clearly >> defined unlike adding arbitrary namespaced elements/attributes >> anywhere. It allows code reuse because the same subsystem for >> dispatching behaviour from core elements can be reused >> to handle dispatching for other rel values. > > else if (element.name=="link") { > href=element.attr("href") > rel=element.attr("rel") > > if (rel=="alternate") { > alternate=href > } else if (rel=="related") { > related=href > } > } else if (element.name="...") { > > vs > > else if (element.name=="alternate") { > alternate=element.attr("href") > } else if (element=="related") { > related=element.attr("href") > } else if (element.name=="...") { > Examples can be constructed to make either way look simpler: switch(element->name()) { case 'link': AddToLinksList(element->attr('rel'), element->attr('href'), element->attr('title')); break; ... } vs. switch(element->name()) { case 'alternate': case 'related': case 'start': case 'prev': case 'next': AddToLinksList(element->name(), element->attr('href'), element->attr('title')); break; ... } As long as the element or elements all have the same structure (are all "Link Constructs"), I don't see that it makes a lot of difference until you start talking about extensibility. From owner-atom-syntax@mail.imc.org Thu Aug 26 18:38:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21618 for ; Thu, 26 Aug 2004 18:38:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMPXt5045802; Thu, 26 Aug 2004 15:25:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QMPXOv045801; Thu, 26 Aug 2004 15:25:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMPWm3045787; Thu, 26 Aug 2004 15:25:32 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[127.0.0.1]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0SgX-0007ys-CA; Thu, 26 Aug 2004 22:25:33 +0000 Message-ID: <412E635B.4010004@franklinmint.fm> Date: Thu, 26 Aug 2004 18:25:31 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray , Paul Hoffman / IMC CC: Atom WG , Joe Gregorio , Mark Nottingham , Mark Pilgrim Subject: Chairs: (Re: PaceIdConstruct) References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> In-Reply-To: <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > I'm getting pushback saying "you're going too fast." So, > while I do believe that Sam's draft language matches the consensus I've > inferred from the last few weeks of email on this subject, I suppose we > should hold on for a bit to give other people a chance to object... Sam has made several updates to this Pace based on feedback, and Mark N. has proposed some reasonable changes: http://www.imc.org/atom-syntax/mail-archive/msg08698.html http://www.imc.org/atom-syntax/mail-archive/msg08691.html The consensus remains the same and the Pace has been improved. This "debate" could really use a new draft, IMHO. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 26 18:57:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22468 for ; Thu, 26 Aug 2004 18:57:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMovgI047171; Thu, 26 Aug 2004 15:50:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QMovxK047170; Thu, 26 Aug 2004 15:50:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QMouAe047162 for ; Thu, 26 Aug 2004 15:50:56 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7QMp4Lx029721; Thu, 26 Aug 2004 18:51:04 -0400 Message-ID: <412E6953.6010704@intertwingly.net> Date: Thu, 26 Aug 2004 18:50:59 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom WG Subject: Re: Chairs: (Re: PaceIdConstruct) References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> <412E635B.4010004@franklinmint.fm> In-Reply-To: <412E635B.4010004@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Tim Bray wrote: > >> I'm getting pushback saying "you're going too fast." So, while I do >> believe that Sam's draft language matches the consensus I've inferred >> from the last few weeks of email on this subject, I suppose we should >> hold on for a bit to give other people a chance to object... > > Sam has made several updates to this Pace based on feedback, and Mark N. > has proposed some reasonable changes: > > http://www.imc.org/atom-syntax/mail-archive/msg08698.html > http://www.imc.org/atom-syntax/mail-archive/msg08691.html > > The consensus remains the same and the Pace has been improved. This > "debate" could really use a new draft, IMHO. If the next draft were to omit the words "If the identified resource is served dynamically, the content of an Identification construct MUST be created only once and then stored along with the resource. The content of an Identification construct MUST NOT be created dynamically.", I would not object. The requirement is covered elsewhere. I am also OK with Mark's proposed "...is changed in content or location (e.g., ...)" The examples were straight from the proposed Namespaces in XML 1.1 document, so I gather that the editor of the Atom Syndication Format specification disagrees with the editors of the Namespaces in XML 1.1 document on on the number and types of examples a document of this nature should have. My leanings are to have more. Yes, at this time, a new draft would be most welcome. > Robert Sayre - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 26 19:10:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23285 for ; Thu, 26 Aug 2004 19:10:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QN4qHh048183; Thu, 26 Aug 2004 16:04:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QN4qt7048182; Thu, 26 Aug 2004 16:04:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QN4mI6048168 for ; Thu, 26 Aug 2004 16:04:52 -0700 (PDT) (envelope-from hildjj@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so225492rnk for ; Thu, 26 Aug 2004 16:04:48 -0700 (PDT) Received: by 10.38.70.46 with SMTP id s46mr2762401rna; Thu, 26 Aug 2004 16:04:48 -0700 (PDT) Received: by 10.38.15.47 with HTTP; Thu, 26 Aug 2004 16:04:48 -0700 (PDT) Message-ID: <82777bea04082616044c37cd1a@mail.gmail.com> Date: Thu, 26 Aug 2004 17:04:48 -0600 From: Joe Hildebrand Reply-To: Joe Hildebrand To: atom-syntax@imc.org Subject: Re: Transporting Atom Notifications over the XMLPP In-Reply-To: <5A76B808-F6A0-11D8-8422-000A959A17A6@cursive.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408231547.BOE99812@ms8.netsolmail.com> <412BC0C3.20407@intertwingly.net> <82777bea04082501091a292784@mail.gmail.com> <412C96EC.8050400@intertwingly.net> <5A76B808-F6A0-11D8-8422-000A959A17A6@cursive.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit After a chat with Bob Wyman who has already done a ton of work in this space, I see that my answer below wasn't right. Option 2 is probably the closest. What if the pub/sub ID was formed like this: atom-feed-url?atom:id where the atom-feed-url is the feed that you read the item from, not the "original" feed. This would make it more difficult for people to overwrite others' entries in pub/sub. It would be up to receivers to do cross-feed duplicate detection, using the atom:id's on the items themselves. On Wed, 25 Aug 2004 08:09:18 -0600, Joe Hildebrand wrote: > This is as good a forum as any to discuss it, and we're certainly > willing to make mods to suit the community on both sides. > > On your options: > > 1) this would work. I don't see any downside, but it's pretty hard to > enforce. > 2) I don't think this is right. No need for yet another GUID-y thing > in the world. > 3) This is probably right. For example, I wouldn't want to have people > look at the pub/sub ID and not the atom:id in order to do uniqueness > checks. That would be a layering problem. > > -- > Joe Hildebrand > Denver, CO, USA > > > > On Aug 25, 2004, at 7:41 AM, Sam Ruby wrote: > > > > > Joe Hildebrand wrote: > > > >> Without addressing the formatting issues associated with atom:id's, > >> yes, I think it would be useful to use the atom:id as the pubsub item > >> ID. Item ID's have the nice property that if I publish another item > >> with the same ID, the old item gets replaced. > > > > What's the process for getting draft-saintandre-atompub-notify updated? > > > > I see three basic approaches, which I will list in my order of > > preference: > > > > 1) decide that the pubsub item ID MUST be the same as the atom:id when > > transporting Atom notifications over the XMLPP. > > > > 2) decide that atom:id and pubsub item ID are orthogonal concepts and > > discourage (either implicitly via examples, or explicitly via prose) > > these concepts from being confused. > > > > 3) decide that atom:id SHOULD be used as the pubsub item ID, but that > > consumers MUST NOT presume that they are the same. > > > > - Sam Ruby > > > > -- Joe Hildebrand From owner-atom-syntax@mail.imc.org Thu Aug 26 19:37:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24797 for ; Thu, 26 Aug 2004 19:37:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNS4kU049900; Thu, 26 Aug 2004 16:28:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QNS4Qf049899; Thu, 26 Aug 2004 16:28:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNS3YX049892 for ; Thu, 26 Aug 2004 16:28:03 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7QNSCOV031487; Thu, 26 Aug 2004 19:28:12 -0400 Message-ID: <412E7207.9060800@intertwingly.net> Date: Thu, 26 Aug 2004 19:28:07 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: atom-syntax@imc.org Subject: Re: Transporting Atom Notifications over the XMLPP References: <200408231547.BOE99812@ms8.netsolmail.com> <412BC0C3.20407@intertwingly.net> <82777bea04082501091a292784@mail.gmail.com> <412C96EC.8050400@intertwingly.net> <5A76B808-F6A0-11D8-8422-000A959A17A6@cursive.net> <82777bea04082616044c37cd1a@mail.gmail.com> In-Reply-To: <82777bea04082616044c37cd1a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > After a chat with Bob Wyman who has already done a ton of work in this > space, I see that my answer below wasn't right. > > Option 2 is probably the closest. What if the pub/sub ID was formed like this: > > atom-feed-url?atom:id > > where the atom-feed-url is the feed that you read the item from, not > the "original" feed. This would make it more difficult for people to > overwrite others' entries in pub/sub. It would be up to receivers to > do cross-feed duplicate detection, using the atom:id's on the items > themselves. It seems to me that the pub/sub ItemID only needs to be unique relative to the node, so in general, it will take less characters to make a given ItemID unique than an atom:id. I'm leery of the suggestion of a question mark as feeds URIs may already have a question mark in them. Like some of Dare's category feeds. Or some of the early blosxom feeds. Finally, I'm not sure what problem we are trying to solve here. atom:id are meant to be globally unique. Yes, spoofing is a potential problem, but I don't see how placing a requirement on the same people who are providing the atom:id to provide non-spoofed ItemID solves the problem. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 26 19:37:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24812 for ; Thu, 26 Aug 2004 19:37:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNU2t6049993; Thu, 26 Aug 2004 16:30:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QNU24w049992; Thu, 26 Aug 2004 16:30:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QNU21h049981 for ; Thu, 26 Aug 2004 16:30:02 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040826233003.81730.qmail@web41207.mail.yahoo.com> Received: from [207.46.238.146] by web41207.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 16:30:02 PDT Date: Thu, 26 Aug 2004 16:30:02 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? To: Ian Davis , Atom Syntax In-Reply-To: <412E4398.7040008@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > > It seems to me that there's a lot of energy going > into solving a > relatively minor issue: that of duplicate entries. > There may be other > ways to solve the problem. All the solutions you propose are more brittle than using IDs. In fact on rereading them you don't really propose any solutions. More importantly there is consensus on using URIs as IDs. It seems we are down to Mark and Sam who are still arguing for canonicalization instead of following the example set by W3C specs like XML namespaces and RDF. I think we should just vote on this and move on. > 1. Some way to declare that a feed is an aggregate > or filtered version > of other feeds? List the other feeds so clients can > check if the user is > subcribed to any of those. If so, duplicates should > be expected. These > can be detected by comparing links, titles and > descriptions as is done > in RSS at the moment. The client has some hints > about where to look so > the scale of the problem is reduced. How exactly is it done in RSS at the moment? As far as I am aware, it isn't. Perhaps one of the other aggregator authors can correct me. > 2. A way to declare that the feed will never contain > duplicates. This > can be true in many situations - most weblogs dont't > repeat themselves > and lots of publishing tools can be configured not > to show an entry in > the feed again if it has just been edited. This > would also be suitable > for event driven feeds such as CVS checkins or log > files. In fact I > believe there are many many feeds that can guarantee > not to repeat > entries, barring system errors. The problem isn't knowing which feeds don't have duplicates but actually dealing with duplicates in the ones that do. > 3. A way to include a version number in an entry. > Clients could decide > not to show an entry if it's not the first version. > Publishers would > change the version number if they change the content > of the entry. How does this help exactly? How exactly does this prevent seeing duplicate posts if you are subscribed to a Feedster feed or reading my blog from both http://blogs.msdn.com & http://blogs.msdn.com/dareobasanjo ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 26 19:39:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24950 for ; Thu, 26 Aug 2004 19:39:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNWOwb050178; Thu, 26 Aug 2004 16:32:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QNWOrF050177; Thu, 26 Aug 2004 16:32:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNWMvo050168 for ; Thu, 26 Aug 2004 16:32:22 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7QNWRil018279 for ; Thu, 26 Aug 2004 17:32:27 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3200DUNUQ3IY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 26 Aug 2004 17:32:27 -0600 (MDT) Received: from [192.168.1.2] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I3200CH7UQ2E1@mail.sun.net> for atom-syntax@imc.org; Thu, 26 Aug 2004 17:32:27 -0600 (MDT) Date: Thu, 26 Aug 2004 16:32:22 -0700 From: Tim Bray Subject: Re: Chairs: (Re: PaceIdConstruct) In-reply-to: <412E6953.6010704@intertwingly.net> To: Atom WG Cc: Robert Sayre , Sam Ruby , Mark Nottingham Message-id: <2E44377B-F7B8-11D8-BAB9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <0E2D7D56-F1FC-11D8-99EE-000A95A51C9E@sun.com> <35051FE4-F221-11D8-99EE-000A95A51C9E@sun.com> <412E635B.4010004@franklinmint.fm> <412E6953.6010704@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 26, 2004, at 3:50 PM, Sam Ruby wrote: > The examples were straight from the proposed Namespaces in XML 1.1 > document, so I gather that the editor of the Atom Syndication Format > specification disagrees with the editors of the Namespaces in XML 1.1 > document on on the number and types of examples a document of this > nature should have. My leanings are to have more. As it stands, PaceIdConstruct has exactly two examples. I would be very unhappy if they were lost. Paul spoke for the chairs here: http://imc.org/atom-syntax/mail-archive/msg08760.html - Graham had some issues around the wording and agreed, in the case where he doesn't like the way it shows up in the draft, to draft an improvement: http://imc.org/atom-syntax/mail-archive/msg08786.html Since then, we've had another flurry of messages, but I still think letting MNot take a crack at working PaceIdConstruct into a format-02 draft, then suggesting improvements to that, is the most constructive way forward. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 26 19:42:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25095 for ; Thu, 26 Aug 2004 19:42:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7QNa2NV050402; Thu, 26 Aug 2004 16:36:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7QNa2gq050401; Thu, 26 Aug 2004 16:36:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7QNa2W9050390 for ; Thu, 26 Aug 2004 16:36:02 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 21509 invoked from network); 26 Aug 2004 23:36:04 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 26 Aug 2004 23:36:04 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412E73EE.1030300@internetalchemy.org> Date: Fri, 27 Aug 2004 00:36:14 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <5C617A5A-F7A5-11D8-ABD6-003065EA6144@geckotribe.com> In-Reply-To: <5C617A5A-F7A5-11D8-ABD6-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26/08/2004 22:17, Antone Roundy wrote: > > On Thursday, August 26, 2004, at 02:10 PM, Ian Davis wrote: > >> It seems to me that there's a lot of energy going into solving a >> relatively minor issue: that of duplicate entries. There may be other >> ways to solve the problem. > > While it's good to think out of the box, this sounds like a lot more > trouble than minting unique IDs. Several thousand messages discussing globally unique for all time identifiers sure seems like a lot of trouble to me. (As an aside, can someone give a good example of a globally unique for all time identifier in the real world?) The subtext of my original message was: how important is the duplicate entry problem compared to getting a clean Atom core out of the door? >> 1. Some way to declare that a feed is an aggregate or filtered version >> of other feeds? List the other feeds so clients can check if the user >> is subcribed to any of those. If so, duplicates should be expected. >> These can be detected by comparing links, titles and descriptions as >> is done in RSS at the moment. The client has some hints about where to >> look so the scale of the problem is reduced. > > Aside form this being a lot more work and more prone to error, what do > you do if a feed is an aggregate or filtered version of a number of > aggregate or filtered feeds? You could get to the point where the list > of source feeds is longer than the feed itself. I don't agree that it's more prone to error than the current ID proposals. Enumerating the list of aggregated feeds is a publisher problem. Comparing IDs is a client problem. There are a lot more clients than publishers. Yes, it's more work for the publisher. But not a lot more work since most aggregation is automated and the aggregator has to maintain a list of source feeds anyway. I think this information would be useful to clients. If the user adds a subscription to a new feed, the client could inform them that they are already subscribed via another aggregate feed. >> 2. A way to declare that the feed will never contain duplicates. This >> can be true in many situations - most weblogs dont't repeat themselves >> and lots of publishing tools can be configured not to show an entry in >> the feed again if it has just been edited. This would also be suitable >> for event driven feeds such as CVS checkins or log files. In fact I >> believe there are many many feeds that can guarantee not to repeat >> entries, barring system errors. > > So what happens if you post an entry, and then before it has made its > way off the end of the feed, you edit it? Do you leave the data in the > feed as originally posted? Or do you modify the data in the feed? If > you do, how should the fact that it's the same entry be detected? If > comparing titles, links, and descriptions were fool-proof, IDs may never > have been suggested at all. If you're declaring that your feed never contains duplicates then you ensure that it doesn't by not blindly including edited entries. If you can't ensure that then don't make the declaration. >> 3. A way to include a version number in an entry. Clients could decide >> not to show an entry if it's not the first version. Publishers would >> change the version number if they change the content of the entry. > > What if the first version of the entry was posted and then modified > before you saw it? You'd miss it completely. Yes. Which happens all the time unless you poll insanely fast. It is very common to get gaps in feeds. Perhaps while you sleep or go for a walk you switch your computer off and it misses a few items. No big deal. Ian From owner-atom-syntax@mail.imc.org Thu Aug 26 20:33:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27507 for ; Thu, 26 Aug 2004 20:33:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R0IMVD053594; Thu, 26 Aug 2004 17:18:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R0IMvk053593; Thu, 26 Aug 2004 17:18:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R0ILnJ053587 for ; Thu, 26 Aug 2004 17:18:22 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 38314 invoked from network); 27 Aug 2004 00:18:26 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 00:18:26 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412E7DDD.6070700@internetalchemy.org> Date: Fri, 27 Aug 2004 01:18:37 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> In-Reply-To: <20040826233003.81730.qmail@web41207.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 00:30, Dare Obasanjo wrote: > All the solutions you propose are more brittle than > using IDs. In fact on rereading them you don't really > propose any solutions. More importantly there is > consensus on using URIs as IDs. It seems we are down > to Mark and Sam who are still arguing for > canonicalization instead of following the example set > by W3C specs like XML namespaces and RDF. > > I think we should just vote on this and move on. I've come to the conclusion that requiring every entry to have a globally unique ID is just too onerous for the benefit it provides. How important is the duplicates problem? Is it more annoying than getting two copies of this message because I've CC'd the list? Will you delete one and get on with your life or complain to your email software provider? It's important to get a handle on the importance of the problem because the proposed solution is IMHO going to act a a barrier to innovation around Atom. To be clear, the current solution is going to require that *every* entry in *every* feed contains a globally and temporally unique ID. That includes feeds that consist of CVS checkins, logging notifications, editorial diffs to the Atom draft, stock prices, weather reports, school closure notices, traffic reports, feed validator results, search engine results, POP3 mailbox listings. Why should a publisher be required to generated an ID for an entry that exists only in the feed only for as long as there are no more than x more recent entries, e.g. a web server error log? Fundamentally, the constraints on ID are unenforceable. How is a validator going to check whether the IDs in my feed are globally and temporally unique? Will it keep a list of every ID ever seen? If so, how is it to detect that two different entries that share the same ID are in fact the same? This is exactly the same problem you currently face with RSS. If a validator can't check it then I can be lazy and just hard code my IDs in my feed http://example.com/1 through http://example.com/15. You can't point at my feed and say it's breaking the RFC because you have to compare against the history, which only exists in archive.org and google.com. When your users complain that your aggregator doesn't show new items in my feed then what are you going to do? IDs *will* be reused. I guarantee it. Being the wrong thing to do doesn't stop it from happening. People will change hosting providers and assign new IDs across their entire history. They're still globally unique and have never been used before. I could even argue that they're new items, since they're now part of a new website. These will appear as duplicates to your customers and you can't prevent that happening. Aggregators will aggregate non-Atom content such as RSS and republish as Atom. Where will the ID come from? A new one will have to be generated. If the original source also happened to have a parallel Atom feed then your customers will see the aggregate entries as duplicates and once again you can't prevent that. In fact, even if the original source doesn't have an Atom feed you're probably going to see duplicates since the aggregator will not be able to determine whether two RSS items are the same by looking at the link, title and description. This is too hard a problem as you have pointed out. Therefore each item will get a new Atom ID. More duplicates. I'm going to speculate here and suggest that a large proportion of current duplicates in feeds are generated by linkbloggers. You know the type, they quote an entry and add maybe a tiny comment at the end. Essentially it's a duplicate of the original. ID is not going to solve this either. Which all leaves me wondering just how useful *is* Atom's ID? Ian From owner-atom-syntax@mail.imc.org Thu Aug 26 20:45:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28159 for ; Thu, 26 Aug 2004 20:45:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R0ZjD8054950; Thu, 26 Aug 2004 17:35:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R0Zjvw054949; Thu, 26 Aug 2004 17:35:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R0ZhIn054940 for ; Thu, 26 Aug 2004 17:35:44 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so209104rnk for ; Thu, 26 Aug 2004 17:35:41 -0700 (PDT) Received: by 10.38.72.72 with SMTP id u72mr2774953rna; Thu, 26 Aug 2004 17:35:41 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Thu, 26 Aug 2004 17:35:41 -0700 (PDT) Message-ID: <14be96d3040826173559a5f3f@mail.gmail.com> Date: Thu, 26 Aug 2004 20:35:41 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? Cc: Ian Davis , Atom Syntax In-Reply-To: <20040826233003.81730.qmail@web41207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 16:30:02 -0700 (PDT), Dare Obasanjo wrote: > I think we should just vote on this and move on. Yeah, since that worked so well the last time. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu Aug 26 21:20:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00037 for ; Thu, 26 Aug 2004 21:20:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R135dg056524; Thu, 26 Aug 2004 18:03:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R135aD056523; Thu, 26 Aug 2004 18:03:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R132ov056516; Thu, 26 Aug 2004 18:03:03 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <412E7DDD.6070700@internetalchemy.org> References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> <412E7DDD.6070700@internetalchemy.org> Date: Thu, 26 Aug 2004 18:03:11 -0700 To: Ian Davis From: Paul Hoffman / IMC Subject: Re: ID - wrong solution to the problem? Cc: Atom Syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:18 AM +0100 8/27/04, Ian Davis wrote: >I've come to the conclusion that requiring every entry to have a >globally unique ID is just too onerous for the benefit it provides. Sorry, I haven't seen where in these threads you have shown how it is onerous. Many people (including me) have shown how easy it is. So, even if the benefit is small or limited to one type of user, you need to show how onerous it really is (and thus how those of us who show that it is easy are wrong), not how little you consider the price. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 26 21:29:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00577 for ; Thu, 26 Aug 2004 21:29:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1Jaav057645; Thu, 26 Aug 2004 18:19:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R1JaLd057643; Thu, 26 Aug 2004 18:19:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R1JZeN057629 for ; Thu, 26 Aug 2004 18:19:35 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 68798 invoked from network); 27 Aug 2004 01:19:40 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 01:19:40 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412E8C36.9070605@internetalchemy.org> Date: Fri, 27 Aug 2004 02:19:50 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> <412E7DDD.6070700@internetalchemy.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 02:03, Paul Hoffman / IMC wrote: > Sorry, I haven't seen where in these threads you have shown how it is > onerous. Many people (including me) have shown how easy it is. So, even > if the benefit is small or limited to one type of user, you need to show > how onerous it really is (and thus how those of us who show that it is > easy are wrong), not how little you consider the price. In my previous message I listed a set of potential feed types where I believe generation of an ID is onerous. The reasoning being that these feeds consists either of transient information (traffic reports etc) or large numbers of tiny entries (CVS checkins etc) or both (search engine results, editorial diffs to the Atom draft etc). Producing IDs for these kinds of feeds wastes resource on the producing side because the producer knows that they are never duplicated and that they will exist only for a short period of time. This is exacerbated if canonicalisation is required. It wastes resources on the consumer side because these IDs have to be stored and checked against every other entry the client ever sees. Again, this may mean convoluted URI comparisons. Perhaps onerous is too strong a word but I certainly feel that requiring a globally and temporally unique ID for everything is overkill. That's why I'm quetioning the basis for inclusion of ID in the first place. I don't think it solves the problem it was intended to solve and it places additional responsibilities on both producer and consumer. Ian From owner-atom-syntax@mail.imc.org Thu Aug 26 21:33:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00913 for ; Thu, 26 Aug 2004 21:33:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1QaLU058056; Thu, 26 Aug 2004 18:26:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R1QanI058055; Thu, 26 Aug 2004 18:26:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R1Qacu058048 for ; Thu, 26 Aug 2004 18:26:36 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 71543 invoked from network); 27 Aug 2004 01:26:41 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 01:26:41 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412E8DDB.2070607@internetalchemy.org> Date: Fri, 27 Aug 2004 02:26:51 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> <412E7DDD.6070700@internetalchemy.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Another issue with ID is denial of service. If I want to suppress a competitor's feed then I just pump my feed full of bogus entries using their ID generation scheme. If my feed is fetched first then the client will mark my competitors entries as duplicates of mine. Just to be sure, I'll make sure the dates are set to some time in the past so the bogus entries don't display in the users newsreaders. Ian From owner-atom-syntax@mail.imc.org Thu Aug 26 21:44:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01587 for ; Thu, 26 Aug 2004 21:44:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1XZw9058431; Thu, 26 Aug 2004 18:33:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R1XZqk058430; Thu, 26 Aug 2004 18:33:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1XYdT058422 for ; Thu, 26 Aug 2004 18:33:34 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7R1X6T6028126; Thu, 26 Aug 2004 21:33:06 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOS86010 (AUTH bob@wyman.us); Thu, 26 Aug 2004 21:33:05 -0400 (EDT) Message-Id: <200408270133.BOS86010@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Ian Davis'" , "'Antone Roundy'" Cc: Subject: RE: ID - wrong solution to the problem? Date: Thu, 26 Aug 2004 21:31:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSLxxuKkn10CMt5TYiVfI/NDpVeawADV4og X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <412E73EE.1030300@internetalchemy.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > If the user adds a subscription to a new feed, the client could > inform them that they are already subscribed via another aggregate feed. What you suggest could only happen if aggregate feeds contained all the content of the feeds that they aggregate. However, many feeds are composed of subsets of feeds. Given two aggregate feeds, even if they have the same source feeds, it could make sense to subscribe to both since they may contain non-overlapping subsets of their source feeds. > Enumerating the list of aggregated feeds is a publisher problem. ... > There are a lot more clients than publishers. PubSub.com aggregates over three million feeds. If we were to include the list of three million (and growing) in every feed we generate, this "publisher problem" would turn into a "client problem" very quickly. > Yes, it's more work for the publisher. But not a lot more work since > most aggregation is automated and the aggregator has to maintain a > list of source feeds anyway. You seem to speak with some authority here. Can you point us to the aggregator that you maintain and from which you have learned how easy it is to build aggregators? bob wyman From owner-atom-syntax@mail.imc.org Thu Aug 26 21:48:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01955 for ; Thu, 26 Aug 2004 21:48:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1fIUh059391; Thu, 26 Aug 2004 18:41:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R1fILI059390; Thu, 26 Aug 2004 18:41:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1fHQK059370 for ; Thu, 26 Aug 2004 18:41:18 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id C17B0171D90; Thu, 26 Aug 2004 21:41:18 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Ian Davis'" Cc: "'Atom Syntax'" Subject: RE: ID - wrong solution to the problem? Date: Thu, 26 Aug 2004 21:39:20 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSLzjYTBVwPMrSRS0qAEpSNl6XSnAAB83ow X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <412E7DDD.6070700@internetalchemy.org> Message-Id: <20040827014118.C17B0171D90@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > Which all leaves me wondering just how useful *is* Atom's ID? As defined, the atom:id is only useful in the context of a single feed. While it is required to be globally unique, no mechanisms are provided to ensure global uniqueness or verification of uniqueness... People are trying to figure out, without much luck, how to make atom:id useful in a cross-feed or multi-feed context. This is because the problem of duplicates is a *very* major one for many users -- even if you don't see it that way. The debates here are about what is hoped for; we've yet to deal with reality. bob wyman From owner-atom-syntax@mail.imc.org Thu Aug 26 21:53:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02211 for ; Thu, 26 Aug 2004 21:53:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1kklZ060023; Thu, 26 Aug 2004 18:46:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R1kkGe060022; Thu, 26 Aug 2004 18:46:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R1kjum060001 for ; Thu, 26 Aug 2004 18:46:45 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040827014647.55271.qmail@web41202.mail.yahoo.com> Received: from [131.107.76.30] by web41202.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 18:46:47 PDT Date: Thu, 26 Aug 2004 18:46:47 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? To: Ian Davis , Paul Hoffman / IMC Cc: Atom Syntax In-Reply-To: <412E8C36.9070605@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > In my previous message I listed a set of potential > feed types where I > believe generation of an ID is onerous. The > reasoning being that these > feeds consists either of transient information > (traffic reports etc) or > large numbers of tiny entries (CVS checkins etc) or > both (search engine > results, editorial diffs to the Atom draft etc). You still haven't explained how this is onerous. The amount of code it takes to create a new unique identifier in C# is basically string identifier = uriScheme + myDomainName + DateTime.Now.ToString() + Guid.NewGuid().ToString() How the heck is that onerous? You've just claimed that you think these entries are not worth having unique identifers. > Producing IDs for these kinds of feeds wastes > resource on the producing > side because the producer knows that they are never > duplicated and that > they will exist only for a short period of time. > This is exacerbated if > canonicalisation is required. Again, I await your explanation as to how the one line of code above 'wastes resources' on a web server. Is it running on a 4MHz CPU? > It wastes resources on the consumer side because > these IDs have to be > stored and checked against every other entry the > client ever sees. > Again, this may mean convoluted URI comparisons. So? I'm an author of an RSS aggregator and I don't think it is an onerous burden to have to track or compare IDs. In fact my users have requested features and reported a number of issues that are dependent on having IDs that actually work in the syndication format. Every aggregator author I know of feels the same way. So exactly who are you speaking for? > Perhaps onerous is too strong a word but I certainly > feel that requiring > a globally and temporally unique ID for everything > is overkill. That's > why I'm quetioning the basis for inclusion of ID in > the first place. I > don't think it solves the problem it was intended to > solve and it places > additional responsibilities on both producer and > consumer. As one of person who's actually an aggregator author instead of playing one on TV, I beg to differ. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 26 22:12:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03101 for ; Thu, 26 Aug 2004 22:12:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R1n7Tb060193; Thu, 26 Aug 2004 18:49:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R1n7bc060192; Thu, 26 Aug 2004 18:49:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41204.mail.yahoo.com (web41204.mail.yahoo.com [66.218.93.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R1n5LV060184 for ; Thu, 26 Aug 2004 18:49:07 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040827014906.29648.qmail@web41204.mail.yahoo.com> Received: from [207.46.238.138] by web41204.mail.yahoo.com via HTTP; Thu, 26 Aug 2004 18:49:06 PDT Date: Thu, 26 Aug 2004 18:49:06 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? To: Ian Davis , Atom Syntax In-Reply-To: <412E8DDB.2070607@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > > Another issue with ID is denial of service. > > If I want to suppress a competitor's feed then I > just pump my feed full > of bogus entries using their ID generation scheme. > If my feed is fetched > first then the client will mark my competitors > entries as duplicates of > mine. Just to be sure, I'll make sure the dates are > set to some time in > the past so the bogus entries don't display in the > users newsreaders. Why do people keep trotting out this hypothetical problem. If this is such a threat why don't you demonstrate this in RSS 2.0 by creating a hostile feed that duplicates the and elements of some website then see how much of a malicious hack this is. I personally have no idea what the impact would be but I'd rather see some proof instead of theoretical problems being raised which although possible today haven't manifested themselves. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Aug 26 22:26:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04057 for ; Thu, 26 Aug 2004 22:26:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R257kq061445; Thu, 26 Aug 2004 19:05:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R257l0061444; Thu, 26 Aug 2004 19:05:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R256uw061438 for ; Thu, 26 Aug 2004 19:05:07 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7R2586i017680; Thu, 26 Aug 2004 22:05:12 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOS94144 (AUTH bob@wyman.us); Thu, 26 Aug 2004 22:05:07 -0400 (EDT) Message-Id: <200408270205.BOS94144@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" , "'Joe Hildebrand'" Cc: Subject: RE: Transporting Atom Notifications over the XMLPP Date: Thu, 26 Aug 2004 22:03:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSLxnegSgzDt4n9TwKB3Nb85g64swAA638g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <412E7207.9060800@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Finally, I'm not sure what problem we are trying to solve here. > atom:id are meant to be globally unique. Yes, spoofing is a > potential problem, There are a number of issues here. Among the more important ones are those that deal with proper layering in the protocol stack. If one takes the atom:id (which is "application" data) and uses it at the channel layer (i.e. XMPP JEP-0060) you end up with some nasty consequences. JEP-0060 says that when two or more messages are passed and have the same id, all but the last sent message can be discarded. Typically, this discarding is performed by a client program; however, it can happen in the channel itself under some circumstances. For instance, if the channel is configured to store temporarily undeliverable messages or if proxies or message queues are in the channel, then the intermediaries are free to discard messages without passing them on to the client. If these messages are discarded in the channel, then the client will never even know they existed. The standard pubsub example is that of someone subscribing to messages issued whenever IBM stock is traded. The idea is to notify the user of changes in the price whenever they occur. In some applications, the user is only interested in the latest price. Thus, it is ok if the channel discards any undelivered messages if more recent copies of the message exist. This would work well if you went on vacation for two weeks... When you got back and restarted your client, you would only get one initial message (the most recent price alert) followed by a normal stream of messages. You would *NOT* receive a copy of every price alert sent during the last two weeks. In many cases, it would be ok for the channel to discard messages with duplicate pubsub ids even if the pubsub ids were the same as the atom:id for the entries passed. However, even without dealing with the issue of spoofing, we can see that for some applications, this is not the correct behavior. For example: If the channel is filtering out sequential edits of a message and only allowing the latest version of the message to be delivered, then you can't build an application that attempts to keep track of the changing state of an entry over time. In the "stock" example above, if you wanted to track "time and volume" to detect trends in price over time, you would want to see all the messages. In a blogging example, you might want to have a system that can show you "diffs" between various states of messages, similar to a CVS system, so that you can enable things like roll-back, etc. You might even just want to write an academic paper about editing/updating habits of bloggers... In any case, you'd need to have your client all the messages generated. What should be learned from these examples is that sometimes you want only the most recent message and other times, you want all the intermediaries. I.e. the correct behavior of the system is not something that can be wired into the channel -- the decision of what to use as the ID seen by the channel is application specific -- not something that can be defined universally. In some cases, the required semantics could be provided by using the atom:id as the pubsub id. In other cases, this would force the channel to "break" the application. In the later cases, the program feeding the channel would have to create new pubsub ids which were different from the atom:ids. In addition to the problems cited above, we must face the fact that given Atom's non-existent security provisions and the absence of mechanisms to enforce the uniqueness of atom:ids, it is exceptionally likely that there *will be* spoofed atom:ids. Someone will get upset by what someone else has written and will attempt to flush the offending comment from the network by issuing a new message with the same atom:id as the offending entry. Even if it isn't intentional, it is inevitable that folk will often make mistakes... The problem of spoofing is easily handled if one can assume that all the atom:ids in a specific feed are created or managed by a single authority or that atom:ids are feed-specific. Basically, if the producer of some feed overwrites his own entries, that should be seen as either intentional or the result of silly behavior for which consequences must be accepted. The problem comes with feeds that carry content from multiple authors or with aggregator clients that read from multiple feeds. For instance, the kind of aggregate feeds that we push over XMPP at PubSub.com or the kind of multi-feed reader such as RSSBandit, etc. Just as aggregate feeds in files cause "special issues", so do aggregate feeds in XMPP XML streams. At PubSub.com, we now read about 3 million RSS/Atom files multiple times each day. Given the Atom requirement that atom:id be propagated whenever an entry is copied to a new feed, we should be creating entries in our XMPP feed which have atom:ids which are the same as what we found in the source feeds. However, given the rules of atom, it is very difficult to detect atom:id spoofing without detailed analysis of each entry. Even with such analysis (which is too expensive to be reasonable), we can't be sure of doing the right thing in all cases. Thus, if we use atom:id for pubsub id, we would end up making it pretty easy for spoofers to attack any entries that get passed through our system. This is not good -- our vulnerability would become rapidly well known and any hope of viability for the service would disappear. That would make me very unhappy... So, please, understand that atom:id is application specific data and should not be confused with XMPP or JEP-0060 channel specific data. The layering here is important to maintain. There may be some cases in which it is reasonable and convenient to use atom:id for the pubsub item id. However, there are many cases in which it is not reasonable. Given this, the specification SHOULD NOT require that the pubsub id be the same as the atom:id. bob wyman From owner-atom-syntax@mail.imc.org Thu Aug 26 22:28:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04244 for ; Thu, 26 Aug 2004 22:28:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R26PgU061539; Thu, 26 Aug 2004 19:06:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R26Pth061538; Thu, 26 Aug 2004 19:06:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R26OS3061530 for ; Thu, 26 Aug 2004 19:06:25 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7R26Zvn009072; Thu, 26 Aug 2004 22:06:35 -0400 Message-ID: <412E9725.90100@intertwingly.net> Date: Thu, 26 Aug 2004 22:06:29 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Davis CC: Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> <412E7DDD.6070700@internetalchemy.org> <412E8C36.9070605@internetalchemy.org> In-Reply-To: <412E8C36.9070605@internetalchemy.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > > In my previous message I listed a set of potential feed types where I > believe generation of an ID is onerous. The reasoning being that these > feeds consists either of transient information (traffic reports etc) or > large numbers of tiny entries (CVS checkins etc) or both (search engine > results, editorial diffs to the Atom draft etc). > > Producing IDs for these kinds of feeds wastes resource on the producing > side because the producer knows that they are never duplicated and that > they will exist only for a short period of time. This is exacerbated if > canonicalisation is required. > > It wastes resources on the consumer side because these IDs have to be > stored and checked against every other entry the client ever sees. > Again, this may mean convoluted URI comparisons. How are these requirements any more onerous than the requirements that every item in RSS 1.0 has a mandatory rdf:about attribute? [1] {item_uri} must be unique with respect to any other rdf:about attributes in the RSS document and is a URI which identifies the item. - Sam Ruby [1] http://web.resource.org/rss/1.0/spec#s5.5 From owner-atom-syntax@mail.imc.org Thu Aug 26 22:32:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04406 for ; Thu, 26 Aug 2004 22:32:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R252uG061435; Thu, 26 Aug 2004 19:05:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R252iY061434; Thu, 26 Aug 2004 19:05:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R24xAt061423; Thu, 26 Aug 2004 19:05:00 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <412E8C36.9070605@internetalchemy.org> References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> <412E7DDD.6070700@internetalchemy.org> <412E8C36.9070605@internetalchemy.org> Date: Thu, 26 Aug 2004 19:05:02 -0700 To: Ian Davis From: Paul Hoffman / IMC Subject: Re: ID - wrong solution to the problem? Cc: Atom Syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:19 AM +0100 8/27/04, Ian Davis wrote: >On 27/08/2004 02:03, Paul Hoffman / IMC wrote: >>Sorry, I haven't seen where in these threads you have shown how it >>is onerous. Many people (including me) have shown how easy it is. >>So, even if the benefit is small or limited to one type of user, >>you need to show how onerous it really is (and thus how those of us >>who show that it is easy are wrong), not how little you consider >>the price. > >In my previous message I listed a set of potential feed types where >I believe generation of an ID is onerous. The reasoning being that >these feeds consists either of transient information (traffic >reports etc) or large numbers of tiny entries (CVS checkins etc) or >both (search engine results, editorial diffs to the Atom draft etc). Are you saying it is onerous to create http://hostname/date-down-to-subseconds/hash-of-content for those? >Producing IDs for these kinds of feeds wastes resource on the >producing side because the producer knows that they are never >duplicated and that they will exist only for a short period of time. >This is exacerbated if canonicalisation is required. "Waste of resources" is not the same as "onerous". If the creator is sure that they will exist only for a short period of time and never be duplicated, http://hostname/date-down-to-subseconds is even easier. >It wastes resources on the consumer side because these IDs have to >be stored and checked against every other entry the client ever >sees. Again, this may mean convoluted URI comparisons. The client doesn't have to store and/or compare them if it doesn't want to. There is no MUST language for that. >Perhaps onerous is too strong a word Agree. > but I certainly feel that requiring a globally and temporally >unique ID for everything is overkill. OK, that's different. > That's why I'm quetioning the basis for inclusion of ID in the >first place. I don't think it solves the problem it was intended to >solve and it places additional responsibilities on both producer and >consumer. A number of folks on the list have given a few different reasons why they really want it, so saying it doesn't solve "the problem it was intended to solve" isn't really the issue. If you feel that it doesn't solve the problems that folks have listed, that's fine, but you need to show that. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 26 22:33:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04450 for ; Thu, 26 Aug 2004 22:33:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R2ABna061781; Thu, 26 Aug 2004 19:10:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R2AB7o061780; Thu, 26 Aug 2004 19:10:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R2ABb2061772 for ; Thu, 26 Aug 2004 19:10:11 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <2004082702101201300rb1bke>; Fri, 27 Aug 2004 02:10:12 +0000 Date: Thu, 26 Aug 2004 20:10:11 -0600 Subject: Re: ID - wrong solution to the problem? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <412E8DDB.2070607@internetalchemy.org> Message-Id: <39F31AAC-F7CE-11D8-ABD6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 26, 2004, at 07:26 PM, Ian Davis wrote: > Another issue with ID is denial of service. > > If I want to suppress a competitor's feed then I just pump my feed > full of bogus entries using their ID generation scheme. If my feed is > fetched first then the client will mark my competitors entries as > duplicates of mine. Just to be sure, I'll make sure the dates are set > to some time in the past so the bogus entries don't display in the > users newsreaders. A solution is to check for duplicate IDs first, and then do some kind of comparison between any entries that do have the same ID (though you shouldn't need to bother doing this if the cached entries are from the same feed--in that case, you can trust that the publisher either isn't reusing IDs or will get enough complaints about his non-spec-compliant feed that he'll quickly quit reusing IDs). This would be a MUCH easier way to weed out duplicates than checking against EVERY other entry you've seen. Given that duplicates ARE a big issue (I don't have references at hand, but this has been said numerous times by aggregator developers here), having IDs certainly sounds better than not having them. > It wastes resources on the consumer side because these IDs have to be > stored and checked against every other entry the client ever sees. > Again, this may mean convoluted URI comparisons. Not if we mandate that IDs be comparable charter-by-character. Sure, some broken publishing tools will get this wrong, but they should be educated quickly by their users complaining about duplicates. I wouldn't think you'd necessarily have to store every ID you've ever seen. If you store them for some period of time, and drop them as they get stale, you shouldn't run into too much trouble with really old entries resurfacing. From owner-atom-syntax@mail.imc.org Thu Aug 26 23:13:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06499 for ; Thu, 26 Aug 2004 23:13:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R32E1W065744; Thu, 26 Aug 2004 20:02:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R32Ekp065743; Thu, 26 Aug 2004 20:02:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R32EWu065732 for ; Thu, 26 Aug 2004 20:02:14 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id 49F77171D90; Thu, 26 Aug 2004 23:02:15 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: ID - wrong solution to the problem? Date: Thu, 26 Aug 2004 23:00:18 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSL3v759CuZpS34T3GywKZW4WKqvgAAmjFg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <39F31AAC-F7CE-11D8-ABD6-003065EA6144@geckotribe.com> Message-Id: <20040827030215.49F77171D90@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > A solution is to check for duplicate IDs first, and then do some > kind of comparison between any entries that do have the same ID Would you mind describing what this "some kind of comparison" might be? What comparison can you do that will allow you to detect a malicious attempt to replace an existing entry? If such a comparison can be defined and shown to work, this whole issue would simply evaporate. bob wyman From owner-atom-syntax@mail.imc.org Thu Aug 26 23:16:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06673 for ; Thu, 26 Aug 2004 23:16:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R2pN5R065069; Thu, 26 Aug 2004 19:51:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R2pNK4065068; Thu, 26 Aug 2004 19:51:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R2pNnR065062 for ; Thu, 26 Aug 2004 19:51:23 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7R2pTOo005757; Thu, 26 Aug 2004 19:51:29 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i7R2pSM0019151; Thu, 26 Aug 2004 19:51:29 -0700 (PDT) In-Reply-To: <412E4398.7040008@internetalchemy.org> References: <412E4398.7040008@internetalchemy.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--696224564; protocol="application/pkcs7-signature" Message-Id: <00AA8BD2-F7D4-11D8-8440-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: ID - wrong solution to the problem? Date: Thu, 26 Aug 2004 19:51:31 -0700 To: Ian Davis X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-5--696224564 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit You've missed out the main use of IDs, which is matching up current entries in the feed with the entries from the last time you loaded the feed, so you can carry over metadata (eg whether the user has looked at it). It is not possible to do this by "comparing links, titles and descriptions". Graham --Apple-Mail-5--696224564 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI3MDI1MTMyWjAjBgkqhkiG9w0BCQQxFgQUAYICG9G54gn7YDFovKzbhKcE WsIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEACfv5/HwGZE31OA+5tQ92UxpC LMHKpzcsW97GSGiQLxsQBubkutpdPooRX+6mHaidTfgY54ydO7HYSnPs2+XEtzO05Jys7H0nRhs8 8gzvtQ6mExFFEjOQMQUrSH+hiyxevaBEksGZiNnosgkCr3puYSkJHd3pzK4GvyX5KWnP7SNZhDto hqW2wLeUh8TzVBJxBbUut34ms/puUzqW6s/6JKSVfNivoGaXS81CsM7l9Zn5B8gRQmnYfnEEWIKp wzM8aBioewmd5SUfS0JVKxqOAbV5lwC5KhwoE9tm+3S4SNSb3I4/S94vZPoRcXTLFpnqTuF+ANbl x+HcKPdp6IeBvAAAAAAAAA== --Apple-Mail-5--696224564-- From owner-atom-syntax@mail.imc.org Thu Aug 26 23:16:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06812 for ; Thu, 26 Aug 2004 23:16:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R2tT07065231; Thu, 26 Aug 2004 19:55:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R2tTjX065230; Thu, 26 Aug 2004 19:55:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R2tT3n065224 for ; Thu, 26 Aug 2004 19:55:29 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7R2tMkN020182; Thu, 26 Aug 2004 19:55:23 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i7R2tKM0020082; Thu, 26 Aug 2004 19:55:22 -0700 (PDT) In-Reply-To: <20C7718B-F7AB-11D8-ABD6-003065EA6144@geckotribe.com> References: <20C7718B-F7AB-11D8-ABD6-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--695992365; protocol="application/pkcs7-signature" Message-Id: <8B11346D-F7D4-11D8-8440-000A95DC3D90@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: Re: PaceLinkRelMechanism Date: Thu, 26 Aug 2004 19:55:23 -0700 To: Antone Roundy X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6--695992365 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Exactly my point Antone. Graham --Apple-Mail-6--695992365 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI3MDI1NTI0WjAjBgkqhkiG9w0BCQQxFgQUJFl41aGp7QMtrI+hcUAuAUOC wxcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAwaOpZMPaZdjc0en8By9IjiV2 T5k2iZjrazQuRYhNyTxP35kVZ/U0Q7zCV0yDmM60C6fKf1NzU/cLftHDwLAIaYdetYEvOBMOxPQG MFQv+jWHkDq9Gzrhyh5mSCVBaPTpGDlEjAjjl8gMZcmvIBl0n4w7HzphKv3y6CGhj+pEyYl7a0C0 zpY+kiWXRthK5gXvOl2SHkhv0JwuyKRBaqcpxrPrWjI2/rNg5bINLfDcA10ukjgktNtr7rFdK0QU de0M6ngeWlNRjUNifPXRNC2UtWvK8aviFMttsofakSnsh5FXPw/sKRWfI3pmepIAUlMLStWaRLyv dPele032QZ/V8wAAAAAAAA== --Apple-Mail-6--695992365-- From owner-atom-syntax@mail.imc.org Fri Aug 27 01:26:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14555 for ; Fri, 27 Aug 2004 01:26:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R5E9tE077184; Thu, 26 Aug 2004 22:14:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R5E9pS077183; Thu, 26 Aug 2004 22:14:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R5E8G6077171 for ; Thu, 26 Aug 2004 22:14:08 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc12) with SMTP id <20040827051410014007rbh1e>; Fri, 27 Aug 2004 05:14:10 +0000 Date: Thu, 26 Aug 2004 23:14:08 -0600 Subject: Re: ID - wrong solution to the problem? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <20040827030215.49F77171D90@mail.pubsub.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 26, 2004, at 09:00 PM, Bob Wyman wrote: > Antone Roundy wrote: >> A solution is to check for duplicate IDs first, and then do some >> kind of comparison between any entries that do have the same ID > Would you mind describing what this "some kind of comparison" might > be? > What comparison can you do that will allow you to detect a malicious > attempt to replace an existing entry? > If such a comparison can be defined and shown to work, this whole > issue would simply evaporate. > I didn't have anything detailed in mind, and I don't imagine it would be foolproof--just better than throwing IDs out altogether and depending ENTIRELY on "some kind of comparison" for duplicate detection. Off the top of my head, pseudocode might look something like this: @existingEntries=lookForIDInDataStore($thisEntry->id); if (!count(@existingEntries)) ProcessNewEntry($thisEntry); else { $idOldEntry=0; foreach $oldEntry (@existingEntries) { if ( ($oldEntry->SourceFeed() == $thisEntry->SourceFeed()) || (entrySimilarity($oldEntry, $thisEntry) > 0.8) ) { $isOldEntry=1; last; } } if ($isOldEntry) UpdateOldEntry($thisEntry); else ProcessNewEntry($thisEntry); } function entrySimilarity($e1, $e2) { $elementCount=0; $similarCount=0; foreach $element (@someListOfElements) { if (strlen($e1->elementValue($element)) || strlen($e1->elementValue($element)) $elementCount++; if (!strcmp($e1->elementValue($element), $e2->elementValue($element))) $similarCount++; /* some more complex comparison routine that could computer a degree of similarity, especially for longer elements like would be useful */ } return $elementCount ? ($similarCount/$elementCount) : 0; } Perhaps particular similarities or differences would be considered more significant than others. For example, if the domain portion of the alternate link is different, that would look more like someone trying to grab someone else's traffic than a changed title. Of course, this is turning into wild speculation that would have to be tested against real attempts to hijack somebody else's feed, and it's starting to feel like sort of like spam filtering. The point, in the context of the discussion, is that most of the extra comparison could be skipped in the vast majority of cases by comparing IDs first and moving on if no match is found. From owner-atom-syntax@mail.imc.org Fri Aug 27 02:30:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02298 for ; Fri, 27 Aug 2004 02:30:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6Huni085151; Thu, 26 Aug 2004 23:17:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R6HuBI085150; Thu, 26 Aug 2004 23:17:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6Htb7085130 for ; Thu, 26 Aug 2004 23:17:55 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id BAE5F7C1EE; Fri, 27 Aug 2004 09:08:29 +0200 (CEST) To: "Antone Roundy" Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <366A89BC-F776-11D8-ABD6-003065EA6144@geckotribe.com> Message-ID: Date: Fri, 27 Aug 2004 08:19:48 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <366A89BC-F776-11D8-ABD6-003065EA6144@geckotribe.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 09:40:09 -0600, Antone Roundy wrote: > By specifying not just canonicalization, but a specific set of > canonicalization rules, hopefully prompting people to use code that > they can be certain will generate ids according to those rules rather > than trusting that the library they're using will do it right. +1. > 1) Will requiring canonicalization according to a set of rules > explicitly set out in the spec yield the benefits outlined above? I believe so, yes. > 2) Will that be too onerous a burden for the benefits it yields? Nah. It's easy to do by the few rules e.g. Mark has enumerated in his article. If atom:id canonicalization is only a SHOULD, these examples can go into an informative appendix as well, if people don't like to «clutter» the specification with it. > 3) Is there a better way to maximize the probability of meeting the goal? Not that I know of, at least. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 02:56:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04130 for ; Fri, 27 Aug 2004 02:56:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6ecsh087781; Thu, 26 Aug 2004 23:40:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R6ecfp087780; Thu, 26 Aug 2004 23:40:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6ebrT087771 for ; Thu, 26 Aug 2004 23:40:37 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2B9EA7C1EE; Fri, 27 Aug 2004 09:31:09 +0200 (CEST) To: mint@franklinmint.fm Cc: Atom-Syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> Message-ID: Date: Fri, 27 Aug 2004 08:42:33 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412E48B6.3020603@franklinmint.fm> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 16:31:50 -0400, Robert Sayre wrote: > I think we're on our twentieth lap here. The only disagreement is from > Mark (anyone else?) on c14n. I'm +1 with Mark on requiring or recommending c14n on publishers (not consumers). -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 02:56:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04157 for ; Fri, 27 Aug 2004 02:56:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6kO8X088348; Thu, 26 Aug 2004 23:46:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R6kONp088347; Thu, 26 Aug 2004 23:46:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6kN5g088337 for ; Thu, 26 Aug 2004 23:46:23 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 530797C1EE; Fri, 27 Aug 2004 09:36:55 +0200 (CEST) Date: Fri, 27 Aug 2004 08:48:20 +0200 To: "Sam Ruby" Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax References: <87smabifw7.fsf@nwalsh.com> <412DBD74.9040904@intertwingly.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <412DBD74.9040904@intertwingly.net> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 06:37:40 -0400, Sam Ruby wrote: > Let me point out that the channel link element is required in every > version of RSS from 0.91 to 1.0 to 2.0. ...Which is exactly why I (and others I know of) can't use RSS for many of the purposes I'd like, but instead hope to be able to use Atom in those areas. Many Atom entries and feeds won't have alternate, human readable (typically HTML) alternatives. Atom is in such cases used more like a transport layer of arbitrary resources. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 03:25:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05626 for ; Fri, 27 Aug 2004 03:25:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R7BHp1091270; Fri, 27 Aug 2004 00:11:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R7BHsX091269; Fri, 27 Aug 2004 00:11:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R7BGp4091256 for ; Fri, 27 Aug 2004 00:11:17 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 699407C22E; Fri, 27 Aug 2004 10:01:48 +0200 (CEST) Date: Fri, 27 Aug 2004 09:13:19 +0200 To: "Julian Reschke" Subject: Re: PaceIdConstruct Cc: Atom-Syntax References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <412CF547.5020704@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke wrote: > If consumers compare them as strings anyway, there's no point in > requiring canonicalization, right? Yes, because if publishers don't canonicalize and normalize, 'http://EXAMPLE.COM/1231' and 'http://example.com/1231' would be string-compared as two different entries, regardless of what the publisher really intended with those URI's. Most likely, the publisher wanted them to be the same. If all publishers normalize, canonicalize and do everything in their power to keep atom:id stable and easy to compare, being an Atom consumer will be easy. If they don't, being an Atom consumer will be hard. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 03:45:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06916 for ; Fri, 27 Aug 2004 03:45:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R7bxkj094368; Fri, 27 Aug 2004 00:37:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R7bxkJ094367; Fri, 27 Aug 2004 00:37:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R7bvBu094339 for ; Fri, 27 Aug 2004 00:37:58 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 4975 invoked by uid 65534); 27 Aug 2004 07:37:51 -0000 Received: from pD9E5132C.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.19.44) by mail.gmx.net (mp006) with SMTP; 27 Aug 2004 09:37:51 +0200 X-Authenticated: #1915285 Message-ID: <412EE4CC.7000403@gmx.de> Date: Fri, 27 Aug 2004 09:37:48 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke > wrote: > >> If consumers compare them as strings anyway, there's no point in >> requiring canonicalization, right? > > > Yes, because if publishers don't canonicalize and normalize, > 'http://EXAMPLE.COM/1231' and 'http://example.com/1231' would be > string-compared as two different entries, regardless of what the > publisher really intended with those URI's. Most likely, the publisher > wanted them to be the same. Well, that's the publisher's problem. If they want two IDs to be the same, they'd better use the same string (as the spec tells them). > If all publishers normalize, canonicalize and do everything in their > power to keep atom:id stable and easy to compare, being an Atom > consumer will be easy. If they don't, being an Atom consumer will be hard. Incorrect. As long as IDs are compared as strings, and both producers and consumers are aware of that, there is no issue. Please don't make things more complicated than needed. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 27 04:35:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09648 for ; Fri, 27 Aug 2004 04:35:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8EhMT099947; Fri, 27 Aug 2004 01:14:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R8EhvL099946; Fri, 27 Aug 2004 01:14:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8Ehj9099912 for ; Fri, 27 Aug 2004 01:14:43 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so1838rnb for ; Fri, 27 Aug 2004 01:14:35 -0700 (PDT) Received: by 10.38.206.45 with SMTP id d45mr27437rng; Fri, 27 Aug 2004 01:14:35 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Fri, 27 Aug 2004 01:14:35 -0700 (PDT) Message-ID: <1f2ed5cd04082701146c2c10f0@mail.gmail.com> Date: Fri, 27 Aug 2004 10:14:35 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: PaceLinkRelMechanism Cc: Atom Syntax In-Reply-To: <67C6B637-F7A6-11D8-8440-000A95DC3D90@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040825182036.83573.qmail@web41202.mail.yahoo.com> <1f2ed5cd0408251153319d3d9c@mail.gmail.com> <41D37C34-F707-11D8-8440-000A95DC3D90@mac.com> <1f2ed5cd0408252339734dbd92@mail.gmail.com> <67C6B637-F7A6-11D8-8440-000A95DC3D90@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 14:25:07 -0700, Graham wrote: > On 25 Aug 2004, at 11:39 pm, Danny Ayers wrote: > > > No it hasn't, though you're welcome to try. > > You get disambiguation because because the structure is clearly > > defined unlike adding arbitrary namespaced elements/attributes > > anywhere. It allows code reuse because the same subsystem for > > dispatching behaviour from core elements can be reused > > to handle dispatching for other rel values. > > else if (element.name=="link") { > href=element.attr("href") > rel=element.attr("rel") > > if (rel=="alternate") { > alternate=href > } else if (rel=="related") { > related=href > } > } else if (element.name="...") { > > vs > > else if (element.name=="alternate") { > alternate=element.attr("href") > } else if (element=="related") { > related=element.attr("href") > } else if (element.name=="...") { > > Okay, so mine (the latter) repeats the attr("href"), which we haven't > in yours (though it'd be easy enough to not repeat it). This is all the > code reuse you get, because after that you have to do semantic-specific > processing. That's why I say the benefits are minimal. > > > I honestly can't see why you have a problem with the notion of using a > > common XML construct for a common range of data structures encountered > > in syndication feeds. > > I have a common with using the element name as a type identifier. You > can reuse the same construct if you like. [typo?] Looking at the code example, I'm not sure we actually disagree about much here. I do think in its current usage (with 20 or so different possible rel values) is overly overloaded. I don't have any problem with using similar constructs to better partition the relationship space: (Ok, no-one seems to like the use of qnames, I'm thinking of swapping that for full URIs in the Pace) The element is just the most convenient in the current spec for this treatment. Take these two: On the surface, there's little to choose between them assuming the link definition in the Pace, and the definition (somewhere) that child elements are taken to apply to their parent. But what about: the category We simply don't have a consistent way of interpreting arbitrary namespaced elements/attributes. The link construct offers a constrained means of expressing a specific kind of relationship. If the current link rel values were factored out into their own elements then the same relationship structure could be used for other non-core relationships, offering a bit more specificity: But basically I really don't care how it's done, I just think there needs to be a more systematic approach to extensions that putting anything anywhere. Atom is expressed in structured markup, why not use it? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Aug 27 05:10:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12049 for ; Fri, 27 Aug 2004 05:10:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8nHlJ017493; Fri, 27 Aug 2004 01:49:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R8nHq6017492; Fri, 27 Aug 2004 01:49:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R8nGJQ017458 for ; Fri, 27 Aug 2004 01:49:16 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 48810 invoked from network); 27 Aug 2004 08:49:13 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 08:49:13 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EF593.3080707@internetalchemy.org> Date: Fri, 27 Aug 2004 09:49:23 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <200408270133.BOS86010@ms8.netsolmail.com> In-Reply-To: <200408270133.BOS86010@ms8.netsolmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 02:31, Bob Wyman wrote: > You seem to speak with some authority here. Can you point us to the > aggregator that you maintain and from which you have learned how easy it is > to build aggregators? Do I have to provide credentials to contribute to this group? myRSS.com is my current activity. theweb.startshere.net was the first back in 1999: http://web.archive.org/web/19991111061935/http://theweb.startshere.net/ Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 05:13:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12397 for ; Fri, 27 Aug 2004 05:13:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8qtif019673; Fri, 27 Aug 2004 01:52:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R8qt2A019672; Fri, 27 Aug 2004 01:52:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R8qs36019661 for ; Fri, 27 Aug 2004 01:52:54 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 50427 invoked from network); 27 Aug 2004 08:52:53 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 08:52:53 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EF670.2070807@internetalchemy.org> Date: Fri, 27 Aug 2004 09:53:04 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <20040827014906.29648.qmail@web41204.mail.yahoo.com> In-Reply-To: <20040827014906.29648.qmail@web41204.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 02:49, Dare Obasanjo wrote: > Why do people keep trotting out this hypothetical > problem. If this is such a threat why don't you > demonstrate this in RSS 2.0 by creating a hostile feed > that duplicates the and elements of some > website then see how much of a malicious hack this is. It's just as theoretical as the notion that unique IDs are going to prevent duplicates. Demonstrate that and then my scenario above becomes rather more concrete. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 05:16:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12544 for ; Fri, 27 Aug 2004 05:16:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8uIlj020923; Fri, 27 Aug 2004 01:56:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R8uImo020922; Fri, 27 Aug 2004 01:56:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R8uHh4020911 for ; Fri, 27 Aug 2004 01:56:17 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 52710 invoked from network); 27 Aug 2004 08:56:16 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 08:56:16 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EF73B.7020708@internetalchemy.org> Date: Fri, 27 Aug 2004 09:56:27 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> <412E7DDD.6070700@internetalchemy.org> <412E8C36.9070605@internetalchemy.org> <412E9725.90100@intertwingly.net> In-Reply-To: <412E9725.90100@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 03:06, Sam Ruby wrote: > How are these requirements any more onerous than the requirements that > every item in RSS 1.0 has a mandatory rdf:about attribute? [1] No more onerous at all. I presume you are making this remark because you assume I think RSS 1.0 is the perfect soution. I suggest you check your facts first because not all of us agree with that particular restriction: http://internetalchemy.org/2002/12/rss1Dot0IssuesList#issue3 I woud like to see it removed from RSS 1.0 and not mandatory in Atom. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 05:19:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12680 for ; Fri, 27 Aug 2004 05:19:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R95OlK024457; Fri, 27 Aug 2004 02:05:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R95Ogp024456; Fri, 27 Aug 2004 02:05:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R95NMM024445 for ; Fri, 27 Aug 2004 02:05:23 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 55692 invoked from network); 27 Aug 2004 09:05:23 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 09:05:23 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EF95D.6030204@internetalchemy.org> Date: Fri, 27 Aug 2004 10:05:33 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <200408270133.BOS86010@ms8.netsolmail.com> In-Reply-To: <200408270133.BOS86010@ms8.netsolmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Care to respond to the technical issues rather than my opinions? I'll summarise to make it easier: How important is duplicate detection? How many duplicates are due to aggregation rather than quotation? How is the global and temporal uniqueness of IDs to be checked? How will clients detect old entries that have been reissued IDs? How will aggregates of non-Atom sources determine a suitable ID? Am I missing something? Other than duplicate detection what are the use cases for ID? Ian On 27/08/2004 02:31, Bob Wyman wrote: > Ian Davis wrote: > >>If the user adds a subscription to a new feed, the client could >>inform them that they are already subscribed via another aggregate feed. > > What you suggest could only happen if aggregate feeds contained all > the content of the feeds that they aggregate. However, many feeds are > composed of subsets of feeds. Given two aggregate feeds, even if they have > the same source feeds, it could make sense to subscribe to both since they > may contain non-overlapping subsets of their source feeds. > > >>Enumerating the list of aggregated feeds is a publisher problem. ... >>There are a lot more clients than publishers. > > PubSub.com aggregates over three million feeds. If we were to > include the list of three million (and growing) in every feed we generate, > this "publisher problem" would turn into a "client problem" very quickly. > > >>Yes, it's more work for the publisher. But not a lot more work since >>most aggregation is automated and the aggregator has to maintain a >>list of source feeds anyway. > > You seem to speak with some authority here. Can you point us to the > aggregator that you maintain and from which you have learned how easy it is > to build aggregators? > > bob wyman > > > > > From owner-atom-syntax@mail.imc.org Fri Aug 27 05:20:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12742 for ; Fri, 27 Aug 2004 05:20:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8xPDr022171; Fri, 27 Aug 2004 01:59:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R8xPoU022170; Fri, 27 Aug 2004 01:59:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R8xOan022156 for ; Fri, 27 Aug 2004 01:59:24 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 53634 invoked from network); 27 Aug 2004 08:59:24 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 08:59:24 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EF7F6.6030001@internetalchemy.org> Date: Fri, 27 Aug 2004 09:59:34 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <412E4398.7040008@internetalchemy.org> <00AA8BD2-F7D4-11D8-8440-000A95DC3D90@mac.com> In-Reply-To: <00AA8BD2-F7D4-11D8-8440-000A95DC3D90@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 03:51, Graham wrote: > You've missed out the main use of IDs, which is matching up current > entries in the feed with the entries from the last time you loaded the > feed, so you can carry over metadata (eg whether the user has looked at > it). It is not possible to do this by "comparing links, titles and > descriptions". For this you just need a feed-unique ID not one that's unique for all time and all places. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 05:34:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13401 for ; Fri, 27 Aug 2004 05:34:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R9F7iA028578; Fri, 27 Aug 2004 02:15:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R9F7VK028577; Fri, 27 Aug 2004 02:15:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.afp.com (smtp1.afp.com [158.50.208.108]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R9F63t028501 for ; Fri, 27 Aug 2004 02:15:07 -0700 (PDT) (envelope-from laurent.lemeur@afp.com) Received: by smtp1.afp.com (Sendmail, from userid 1007) id D81684654B; Fri, 27 Aug 2004 11:15:35 +0200 (CEST) Received: from alox.afp.com (unknown [158.50.165.141])by smtp1.afp.com (Sendmail) with ESMTPid BE7BE464F6; Fri, 27 Aug 2004 11:15:35 +0200 (CEST) Received: from sdtc05 (sdtc05.afp.local [158.50.180.103])by alox.afp.com (8.12.9/8.12.9) with ESMTP id i7R9Eot6002411;Fri, 27 Aug 2004 11:14:50 +0200 (METDST) From: "Laurent Le Meur" To: , "'Ian Davis'" , Subject: RE : ID - wrong solution to the problem? Date: Fri, 27 Aug 2004 11:14:51 +0200 Message-ID: <003f01c48c16$4efdedd0$67b4329e@afp.local> MIME-Version: 1.0 Content-Type: text/plain;charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040827030215.49F77171D90@mail.pubsub.com> X-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7R9F73t028570 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Maybe this issue should be looked from the processing perspective only. Unique IDs allow for a smart processing, and they don't impose it. If Atom adopts the unique ID spec, then the processing model can be specified as: - if two IDs are identical (whatever the comparison process is), the recipient (processor) SHOULD assume that the entries are identical (convey the same meaning), are a/ replace any previously received instance of the entry by the last instance or b/ keep both instances (for rollback / piracy detection or other purpose), but only display/send/process the last instance. If versioning is adopted (as an option, with a revision ID and/or a modified date-time convention), the processing model can also be specified as: - if two IDs differ only by a revision id (or a modified date-time), the recipient SHOULD assume that the entry with the higher revision ID (or date) is a new version of the information, are a/ replace any previous revision of the information by the last entry or b/ keep all revisions, but only display/send/process the last revision by default (and display older revisions when needed/requested by a user or administrator). >It wastes resources on the consumer side because these IDs have to >be stored and checked against every other entry the client ever >sees. Again, this may mean convoluted URI comparisons. (Ian Davis) When the ID is a database primary key, comparison (byte-per-byte) is a non issue. Smart URI comparison is another matter, ok. > I certainly feel that requiring a globally and temporally > unique ID for everything is overkill. (Ian Davis) > In my previous message I listed a set of potential feed types where I > believe generation of an ID is onerous. The reasoning being that these > feeds consists either of transient information (traffic reports etc) or > large numbers of tiny entries (CVS checkins etc) or both (search engine > results, editorial diffs to the Atom draft etc). (Ian Davis) So what ... if people create new information with an existing ID, the new information will supersede in all cases the previous information. All the provider has to know is that this is the rule all syndication nodes will follow. > If I want to suppress a competitor's feed then I just pump my feed full > of bogus entries using their ID generation scheme. An optional signature mechanism has been discussed on this list in order to avoid this threat. High level Atom processor should implement this from the start. > How is a validator going to check whether the IDs in my feed are globally and temporally unique? (Ian Davis) > As defined, the atom:id is only useful in the context of a single > feed. While it is required to be globally unique, no mechanisms are > provided to ensure global uniqueness or verification of uniqueness (Bob Wyman) No need to check/validate, as it is only a matter of processing logic. > As an aside, can someone give a good example of a globally unique for all time identifier in the real world? (Ian Davis) NewsML URNs used by press agencies. regards Laurent Le Meur - AVERTISSEMENT Le présent mail et ses pièces jointes sont confidentiels et destinés au seul usage des personnes ou entités auxquelles ils sont adressés. Si vous avez reçu cet e-mail par erreur, veuillez contacter dans les plus brefs délais son expéditeur et effacer le contenu du message de votre système informatique. Toute divulgation, distribution ou copie de cet e-mail est strictement interdite. - DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please contact the sender and delete the email from your system. If you are not the named addressee you should not disseminate, distribute or copy this email. - From owner-atom-syntax@mail.imc.org Fri Aug 27 05:40:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13875 for ; Fri, 27 Aug 2004 05:40:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R9RwJG033408; Fri, 27 Aug 2004 02:27:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R9Rwav033407; Fri, 27 Aug 2004 02:27:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R9RvPC033396 for ; Fri, 27 Aug 2004 02:27:58 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 62800 invoked from network); 27 Aug 2004 09:27:57 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 09:27:57 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EFEA7.7020406@internetalchemy.org> Date: Fri, 27 Aug 2004 10:28:07 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040827014647.55271.qmail@web41202.mail.yahoo.com> In-Reply-To: <20040827014647.55271.qmail@web41202.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 02:46, Dare Obasanjo wrote: > string identifier = uriScheme + myDomainName + > DateTime.Now.ToString() + Guid.NewGuid().ToString() > > How the heck is that onerous? You've just claimed that > you think these entries are not worth having unique > identifers. You need to own a domain name. Most producers of Atom won't and using the domain of the generating software has the issues I described in relation to the tag scheme. .NET is blessed with RNGCryptoServiceProvider that can generate the required degree of randomness for a GUID. Good luck to all those producing Atom feeds via shell scripts, PHP or XSLT. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 05:48:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14821 for ; Fri, 27 Aug 2004 05:48:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R9X4HB035196; Fri, 27 Aug 2004 02:33:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R9X4S2035195; Fri, 27 Aug 2004 02:33:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R9X3TW035176 for ; Fri, 27 Aug 2004 02:33:03 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 64632 invoked from network); 27 Aug 2004 09:33:03 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 09:33:03 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EFFD9.5000508@internetalchemy.org> Date: Fri, 27 Aug 2004 10:33:13 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> <412E7DDD.6070700@internetalchemy.org> <412E8C36.9070605@internetalchemy.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 03:05, Paul Hoffman / IMC wrote: > Are you saying it is onerous to create > http://hostname/date-down-to-subseconds/hash-of-content for those? Yes. Show me how to get the current time in XSLT. > A number of folks on the list have given a few different reasons why > they really want it, so saying it doesn't solve "the problem it was > intended to solve" isn't really the issue. If you feel that it doesn't > solve the problems that folks have listed, that's fine, but you need to > show that. I disagree. Saying it doesn't solve "the problem it was intended to solve" *is* the issue. I believe you should be asking the ID proponents to demonstrate how it solves the problem that is is designed to address. I've provided several arguments to the contrary. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 06:11:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16045 for ; Fri, 27 Aug 2004 06:11:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R9qT7c041973; Fri, 27 Aug 2004 02:52:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R9qTpr041972; Fri, 27 Aug 2004 02:52:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R9qS5c041961 for ; Fri, 27 Aug 2004 02:52:29 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 70947 invoked from network); 27 Aug 2004 09:52:29 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 09:52:29 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412F0466.7080104@internetalchemy.org> Date: Fri, 27 Aug 2004 10:52:38 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurent Le Meur CC: bobwyman@pubsub.com, atom-syntax@imc.org Subject: Re: RE : ID - wrong solution to the problem? References: <003f01c48c16$4efdedd0$67b4329e@afp.local> In-Reply-To: <003f01c48c16$4efdedd0$67b4329e@afp.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 10:14, Laurent Le Meur wrote: > Maybe this issue should be looked from the processing perspective only. > Unique IDs allow for a smart processing, and they don't impose it. You are suggesting that publishers must ensure that all entries have IDs that are canonical, globally unique, have never been used before and will never be used again no matter what publishing mechanism they use on the off-chance that a client might want to compare it with another ID. > >>It wastes resources on the consumer side because these IDs have to >>be stored and checked against every other entry the client ever >>sees. Again, this may mean convoluted URI comparisons. (Ian Davis) > > > When the ID is a database primary key, comparison (byte-per-byte) is a non > issue. Smart URI comparison is another matter, ok. As I suggested in another message, most clients will dump these into a database and index them. If that's the case, why enforce a URI with all the ambiguity that involved. Why not just require a GUID? >>As an aside, can someone give a good example of a globally unique for all > > time identifier in the real world? (Ian Davis) > > NewsML URNs used by press agencies. And even here there are ambiguities around canonicalisation and comparison. From RFC3085: "URNs are lexically equivalent if the ProviderId, DateId, NewsItemId, and RevisionId are all identical (case-insensitive comparison)." Are the following the same: urn:newsml:iptc.org:20001006:NewsMLv1.0:1 urn:newsml:iptc.org:20001006:%4EewsMLv1.0:1 Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 07:41:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21593 for ; Fri, 27 Aug 2004 07:41:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBV8Gj074624; Fri, 27 Aug 2004 04:31:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RBV83L074622; Fri, 27 Aug 2004 04:31:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RBV7EB074593 for ; Fri, 27 Aug 2004 04:31:07 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 9257 invoked from network); 27 Aug 2004 11:31:05 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 11:31:05 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412F1B83.5000809@internetalchemy.org> Date: Fri, 27 Aug 2004 12:31:15 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <200408270133.BOS86010@ms8.netsolmail.com> In-Reply-To: <200408270133.BOS86010@ms8.netsolmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 02:31, Bob Wyman wrote: >>Enumerating the list of aggregated feeds is a publisher problem. ... >>There are a lot more clients than publishers. > > PubSub.com aggregates over three million feeds. If we were to > include the list of three million (and growing) in every feed we generate, > this "publisher problem" would turn into a "client problem" very quickly. Why are you contesting this when your own feeds already include the necessary structure. From http://atom.pubsub.com/c3/cd/7a625435c020f57b2536e64cc6.xml OmniWeb 5.1 Wishlist &#38; RSS News Reading Matt Henderson's Blog Combine this with a feed-unique ID and you may have a usable duplicate detection mechanism. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 07:48:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21938 for ; Fri, 27 Aug 2004 07:48:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBe5mY078148; Fri, 27 Aug 2004 04:40:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RBe5pU078147; Fri, 27 Aug 2004 04:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBe4pN078091 for ; Fri, 27 Aug 2004 04:40:04 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id B9E2D20CCE5 for ; Fri, 27 Aug 2004 12:35:11 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 04:45:11 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 8751F198448; Fri, 27 Aug 2004 04:14:13 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R32E1W065744; Thu, 26 Aug 2004 20:02:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R32Ekp065743; Thu, 26 Aug 2004 20:02:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R32EWu065732 for ; Thu, 26 Aug 2004 20:02:14 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id 49F77171D90; Thu, 26 Aug 2004 23:02:15 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: ID - wrong solution to the problem? Date: Thu, 26 Aug 2004 23:00:18 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSL3v759CuZpS34T3GywKZW4WKqvgAAmjFg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <39F31AAC-F7CE-11D8-ABD6-003065EA6144@geckotribe.com> Message-Id: <20040827030215.49F77171D90@mail.pubsub.com> List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > A solution is to check for duplicate IDs first, and then do some > kind of comparison between any entries that do have the same ID Would you mind describing what this "some kind of comparison" might be? What comparison can you do that will allow you to detect a malicious attempt to replace an existing entry? If such a comparison can be defined and shown to work, this whole issue would simply evaporate. bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 27 08:01:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22863 for ; Fri, 27 Aug 2004 08:01:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBqjxk083299; Fri, 27 Aug 2004 04:52:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RBqjFY083298; Fri, 27 Aug 2004 04:52:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBqiig083206 for ; Fri, 27 Aug 2004 04:52:44 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id D49C220C909 for ; Fri, 27 Aug 2004 12:47:27 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 10:11:54 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id CB915198165; Fri, 27 Aug 2004 10:11:53 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8nHlJ017493; Fri, 27 Aug 2004 01:49:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R8nHq6017492; Fri, 27 Aug 2004 01:49:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R8nGJQ017458 for ; Fri, 27 Aug 2004 01:49:16 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 48810 invoked from network); 27 Aug 2004 08:49:13 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 08:49:13 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EF593.3080707@internetalchemy.org> Date: Fri, 27 Aug 2004 09:49:23 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us Cc: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <200408270133.BOS86010@ms8.netsolmail.com> In-Reply-To: <200408270133.BOS86010@ms8.netsolmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 02:31, Bob Wyman wrote: > You seem to speak with some authority here. Can you point us to the > aggregator that you maintain and from which you have learned how easy it is > to build aggregators? Do I have to provide credentials to contribute to this group? myRSS.com is my current activity. theweb.startshere.net was the first back in 1999: http://web.archive.org/web/19991111061935/http://theweb.startshere.net/ Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 08:02:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22916 for ; Fri, 27 Aug 2004 08:02:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBoVYw082023; Fri, 27 Aug 2004 04:50:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RBoV4R082022; Fri, 27 Aug 2004 04:50:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBoUvX081999 for ; Fri, 27 Aug 2004 04:50:30 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id E01CB20C4CE for ; Fri, 27 Aug 2004 12:46:16 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 09:38:30 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 5534819812A; Fri, 27 Aug 2004 09:38:30 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8EhMT099947; Fri, 27 Aug 2004 01:14:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R8EhvL099946; Fri, 27 Aug 2004 01:14:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8Ehj9099912 for ; Fri, 27 Aug 2004 01:14:43 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so1838rnb for ; Fri, 27 Aug 2004 01:14:35 -0700 (PDT) Received: by 10.38.206.45 with SMTP id d45mr27437rng; Fri, 27 Aug 2004 01:14:35 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Fri, 27 Aug 2004 01:14:35 -0700 (PDT) Message-ID: <1f2ed5cd04082701146c2c10f0@mail.gmail.com> Date: Fri, 27 Aug 2004 10:14:35 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: PaceLinkRelMechanism Cc: Atom Syntax In-Reply-To: <67C6B637-F7A6-11D8-8440-000A95DC3D90@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit References: <20040825182036.83573.qmail@web41202.mail.yahoo.com> <1f2ed5cd0408251153319d3d9c@mail.gmail.com> <41D37C34-F707-11D8-8440-000A95DC3D90@mac.com> <1f2ed5cd0408252339734dbd92@mail.gmail.com> <67C6B637-F7A6-11D8-8440-000A95DC3D90@mac.com> List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 26 Aug 2004 14:25:07 -0700, Graham wrote: > On 25 Aug 2004, at 11:39 pm, Danny Ayers wrote: > > > No it hasn't, though you're welcome to try. > > You get disambiguation because because the structure is clearly > > defined unlike adding arbitrary namespaced elements/attributes > > anywhere. It allows code reuse because the same subsystem for > > dispatching behaviour from core elements can be reused > > to handle dispatching for other rel values. > > else if (element.name=="link") { > href=element.attr("href") > rel=element.attr("rel") > > if (rel=="alternate") { > alternate=href > } else if (rel=="related") { > related=href > } > } else if (element.name="...") { > > vs > > else if (element.name=="alternate") { > alternate=element.attr("href") > } else if (element=="related") { > related=element.attr("href") > } else if (element.name=="...") { > > Okay, so mine (the latter) repeats the attr("href"), which we haven't > in yours (though it'd be easy enough to not repeat it). This is all the > code reuse you get, because after that you have to do semantic-specific > processing. That's why I say the benefits are minimal. > > > I honestly can't see why you have a problem with the notion of using a > > common XML construct for a common range of data structures encountered > > in syndication feeds. > > I have a common with using the element name as a type identifier. You > can reuse the same construct if you like. [typo?] Looking at the code example, I'm not sure we actually disagree about much here. I do think in its current usage (with 20 or so different possible rel values) is overly overloaded. I don't have any problem with using similar constructs to better partition the relationship space: (Ok, no-one seems to like the use of qnames, I'm thinking of swapping that for full URIs in the Pace) The element is just the most convenient in the current spec for this treatment. Take these two: On the surface, there's little to choose between them assuming the link definition in the Pace, and the definition (somewhere) that child elements are taken to apply to their parent. But what about: the category We simply don't have a consistent way of interpreting arbitrary namespaced elements/attributes. The link construct offers a constrained means of expressing a specific kind of relationship. If the current link rel values were factored out into their own elements then the same relationship structure could be used for other non-core relationships, offering a bit more specificity: But basically I really don't care how it's done, I just think there needs to be a more systematic approach to extensions that putting anything anywhere. Atom is expressed in structured markup, why not use it? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Aug 27 08:06:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23421 for ; Fri, 27 Aug 2004 08:06:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBuTge084642; Fri, 27 Aug 2004 04:56:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RBuTqg084641; Fri, 27 Aug 2004 04:56:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBuS5m084609 for ; Fri, 27 Aug 2004 04:56:28 -0700 (PDT) (envelope-from grayrest@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so243310rnk for ; Fri, 27 Aug 2004 04:56:25 -0700 (PDT) Received: by 10.38.70.46 with SMTP id s46mr2991311rna; Fri, 27 Aug 2004 04:56:24 -0700 (PDT) Received: by 10.38.70.69 with HTTP; Fri, 27 Aug 2004 04:56:24 -0700 (PDT) Message-ID: <476b71e80408270456f06f3f@mail.gmail.com> Date: Fri, 27 Aug 2004 07:56:24 -0400 From: grayrest Reply-To: grayrest To: Atom-Syntax Subject: Re: URIs vs Strings In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RBuT5m084635 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 08:42:33 +0200, Asbjørn Ulsberg wrote: > > I think we're on our twentieth lap here. The only disagreement is from > > Mark (anyone else?) on c14n. > > I'm +1 with Mark on requiring or recommending c14n on publishers (not > consumers). I'm not sure if my vote counts, but I'm +1 on c14n for publishers and not consumers. It's not that difficult to normalize your own url and simplifies client implementation. From owner-atom-syntax@mail.imc.org Fri Aug 27 08:07:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23471 for ; Fri, 27 Aug 2004 08:07:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBrDd6083492; Fri, 27 Aug 2004 04:53:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RBrDpE083491; Fri, 27 Aug 2004 04:53:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBrClL083453 for ; Fri, 27 Aug 2004 04:53:12 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 65F3220C203 for ; Fri, 27 Aug 2004 12:48:26 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 10:13:57 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id CE0BB198134; Fri, 27 Aug 2004 10:13:56 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R8qtif019673; Fri, 27 Aug 2004 01:52:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R8qt2A019672; Fri, 27 Aug 2004 01:52:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R8qs36019661 for ; Fri, 27 Aug 2004 01:52:54 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 50427 invoked from network); 27 Aug 2004 08:52:53 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 08:52:53 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412EF670.2070807@internetalchemy.org> Date: Fri, 27 Aug 2004 09:53:04 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo Cc: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <20040827014906.29648.qmail@web41204.mail.yahoo.com> In-Reply-To: <20040827014906.29648.qmail@web41204.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 02:49, Dare Obasanjo wrote: > Why do people keep trotting out this hypothetical > problem. If this is such a threat why don't you > demonstrate this in RSS 2.0 by creating a hostile feed > that duplicates the and elements of some > website then see how much of a malicious hack this is. It's just as theoretical as the notion that unique IDs are going to prevent duplicates. Demonstrate that and then my scenario above becomes rather more concrete. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 08:12:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23820 for ; Fri, 27 Aug 2004 08:12:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC2QIP086994; Fri, 27 Aug 2004 05:02:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RC2QYu086993; Fri, 27 Aug 2004 05:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC2PHx086938 for ; Fri, 27 Aug 2004 05:02:26 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id C71AB20C297 for ; Fri, 27 Aug 2004 13:01:16 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 06:26:23 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 1BEB019812A; Fri, 27 Aug 2004 06:26:22 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R5E9tE077184; Thu, 26 Aug 2004 22:14:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R5E9pS077183; Thu, 26 Aug 2004 22:14:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R5E8G6077171 for ; Thu, 26 Aug 2004 22:14:08 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc12) with SMTP id <20040827051410014007rbh1e>; Fri, 27 Aug 2004 05:14:10 +0000 Date: Thu, 26 Aug 2004 23:14:08 -0600 Subject: Re: ID - wrong solution to the problem? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <20040827030215.49F77171D90@mail.pubsub.com> Message-Id: X-Mailer: Apple Mail (2.553) List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 26, 2004, at 09:00 PM, Bob Wyman wrote: > Antone Roundy wrote: >> A solution is to check for duplicate IDs first, and then do some >> kind of comparison between any entries that do have the same ID > Would you mind describing what this "some kind of comparison" might > be? > What comparison can you do that will allow you to detect a malicious > attempt to replace an existing entry? > If such a comparison can be defined and shown to work, this whole > issue would simply evaporate. > I didn't have anything detailed in mind, and I don't imagine it would be foolproof--just better than throwing IDs out altogether and depending ENTIRELY on "some kind of comparison" for duplicate detection. Off the top of my head, pseudocode might look something like this: @existingEntries=lookForIDInDataStore($thisEntry->id); if (!count(@existingEntries)) ProcessNewEntry($thisEntry); else { $idOldEntry=0; foreach $oldEntry (@existingEntries) { if ( ($oldEntry->SourceFeed() == $thisEntry->SourceFeed()) || (entrySimilarity($oldEntry, $thisEntry) > 0.8) ) { $isOldEntry=1; last; } } if ($isOldEntry) UpdateOldEntry($thisEntry); else ProcessNewEntry($thisEntry); } function entrySimilarity($e1, $e2) { $elementCount=0; $similarCount=0; foreach $element (@someListOfElements) { if (strlen($e1->elementValue($element)) || strlen($e1->elementValue($element)) $elementCount++; if (!strcmp($e1->elementValue($element), $e2->elementValue($element))) $similarCount++; /* some more complex comparison routine that could computer a degree of similarity, especially for longer elements like would be useful */ } return $elementCount ? ($similarCount/$elementCount) : 0; } Perhaps particular similarities or differences would be considered more significant than others. For example, if the domain portion of the alternate link is different, that would look more like someone trying to grab someone else's traffic than a changed title. Of course, this is turning into wild speculation that would have to be tested against real attempts to hijack somebody else's feed, and it's starting to feel like sort of like spam filtering. The point, in the context of the discussion, is that most of the extra comparison could be skipped in the vast majority of cases by comparing IDs first and moving on if no match is found. From owner-atom-syntax@mail.imc.org Fri Aug 27 08:14:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23910 for ; Fri, 27 Aug 2004 08:14:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC5ZZU088346; Fri, 27 Aug 2004 05:05:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RC5Zea088343; Fri, 27 Aug 2004 05:05:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC5YoE088254 for ; Fri, 27 Aug 2004 05:05:34 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id AF63A20C457 for ; Fri, 27 Aug 2004 13:02:27 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 07:56:55 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id DB8AD19814D; Fri, 27 Aug 2004 07:56:54 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6kO8X088348; Thu, 26 Aug 2004 23:46:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R6kONp088347; Thu, 26 Aug 2004 23:46:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6kN5g088337 for ; Thu, 26 Aug 2004 23:46:23 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 530797C1EE; Fri, 27 Aug 2004 09:36:55 +0200 (CEST) Date: Fri, 27 Aug 2004 08:48:20 +0200 To: "Sam Ruby" Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax References: <87smabifw7.fsf@nwalsh.com> <412DBD74.9040904@intertwingly.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <412DBD74.9040904@intertwingly.net> User-Agent: Opera M2/7.60 (Win32, build 7141) List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 06:37:40 -0400, Sam Ruby wrote: > Let me point out that the channel link element is required in every > version of RSS from 0.91 to 1.0 to 2.0. ...Which is exactly why I (and others I know of) can't use RSS for many of the purposes I'd like, but instead hope to be able to use Atom in those areas. Many Atom entries and feeds won't have alternate, human readable (typically HTML) alternatives. Atom is in such cases used more like a transport layer of arbitrary resources. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 08:14:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23933 for ; Fri, 27 Aug 2004 08:14:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC5LGD088204; Fri, 27 Aug 2004 05:05:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RC5L3P088203; Fri, 27 Aug 2004 05:05:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC5KPq088164 for ; Fri, 27 Aug 2004 05:05:21 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 5E4D720C453 for ; Fri, 27 Aug 2004 13:02:27 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 07:31:56 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id C8EA619812A; Fri, 27 Aug 2004 07:31:55 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6Huni085151; Thu, 26 Aug 2004 23:17:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R6HuBI085150; Thu, 26 Aug 2004 23:17:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6Htb7085130 for ; Thu, 26 Aug 2004 23:17:55 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id BAE5F7C1EE; Fri, 27 Aug 2004 09:08:29 +0200 (CEST) To: "Antone Roundy" Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <366A89BC-F776-11D8-ABD6-003065EA6144@geckotribe.com> Message-ID: Date: Fri, 27 Aug 2004 08:19:48 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <366A89BC-F776-11D8-ABD6-003065EA6144@geckotribe.com> User-Agent: Opera M2/7.60 (Win32, build 7141) List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 09:40:09 -0600, Antone Roundy wrote: > By specifying not just canonicalization, but a specific set of > canonicalization rules, hopefully prompting people to use code that > they can be certain will generate ids according to those rules rather > than trusting that the library they're using will do it right. +1. > 1) Will requiring canonicalization according to a set of rules > explicitly set out in the spec yield the benefits outlined above? I believe so, yes. > 2) Will that be too onerous a burden for the benefits it yields? Nah. It's easy to do by the few rules e.g. Mark has enumerated in his article. If atom:id canonicalization is only a SHOULD, these examples can go into an informative appendix as well, if people don't like to «clutter» the specification with it. > 3) Is there a better way to maximize the probability of meeting the goal? Not that I know of, at least. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 08:14:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23957 for ; Fri, 27 Aug 2004 08:14:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC5DYQ088143; Fri, 27 Aug 2004 05:05:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RC5DjU088142; Fri, 27 Aug 2004 05:05:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC5CIf088097 for ; Fri, 27 Aug 2004 05:05:12 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id EAFE320C229 for ; Fri, 27 Aug 2004 13:03:06 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 08:26:15 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id D82F119812A; Fri, 27 Aug 2004 08:26:14 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R7BHp1091270; Fri, 27 Aug 2004 00:11:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R7BHsX091269; Fri, 27 Aug 2004 00:11:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R7BGp4091256 for ; Fri, 27 Aug 2004 00:11:17 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 699407C22E; Fri, 27 Aug 2004 10:01:48 +0200 (CEST) Date: Fri, 27 Aug 2004 09:13:19 +0200 To: "Julian Reschke" Subject: Re: PaceIdConstruct Cc: Atom-Syntax References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <412CF547.5020704@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke wrote: > If consumers compare them as strings anyway, there's no point in > requiring canonicalization, right? Yes, because if publishers don't canonicalize and normalize, 'http://EXAMPLE.COM/1231' and 'http://example.com/1231' would be string-compared as two different entries, regardless of what the publisher really intended with those URI's. Most likely, the publisher wanted them to be the same. If all publishers normalize, canonicalize and do everything in their power to keep atom:id stable and easy to compare, being an Atom consumer will be easy. If they don't, being an Atom consumer will be hard. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 08:15:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24021 for ; Fri, 27 Aug 2004 08:15:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC6D8d088594; Fri, 27 Aug 2004 05:06:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RC6DtF088593; Fri, 27 Aug 2004 05:06:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC6Csc088554 for ; Fri, 27 Aug 2004 05:06:12 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 6E17220C667 for ; Fri, 27 Aug 2004 13:03:55 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 08:45:20 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id BFDEA198132; Fri, 27 Aug 2004 08:45:19 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R7bxkj094368; Fri, 27 Aug 2004 00:37:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R7bxkJ094367; Fri, 27 Aug 2004 00:37:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7R7bvBu094339 for ; Fri, 27 Aug 2004 00:37:58 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 4975 invoked by uid 65534); 27 Aug 2004 07:37:51 -0000 Received: from pD9E5132C.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.19.44) by mail.gmx.net (mp006) with SMTP; 27 Aug 2004 09:37:51 +0200 X-Authenticated: #1915285 Message-ID: <412EE4CC.7000403@gmx.de> Date: Fri, 27 Aug 2004 09:37:48 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke > wrote: > >> If consumers compare them as strings anyway, there's no point in >> requiring canonicalization, right? > > > Yes, because if publishers don't canonicalize and normalize, > 'http://EXAMPLE.COM/1231' and 'http://example.com/1231' would be > string-compared as two different entries, regardless of what the > publisher really intended with those URI's. Most likely, the publisher > wanted them to be the same. Well, that's the publisher's problem. If they want two IDs to be the same, they'd better use the same string (as the spec tells them). > If all publishers normalize, canonicalize and do everything in their > power to keep atom:id stable and easy to compare, being an Atom > consumer will be easy. If they don't, being an Atom consumer will be hard. Incorrect. As long as IDs are compared as strings, and both producers and consumers are aware of that, there is no issue. Please don't make things more complicated than needed. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 27 08:15:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24069 for ; Fri, 27 Aug 2004 08:15:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC5qwT088474; Fri, 27 Aug 2004 05:05:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RC5qDu088473; Fri, 27 Aug 2004 05:05:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out-ldn-01.macmillan.co.uk (smtp-out-ldn-01.macmillan.co.uk [194.129.50.174]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC5qKE088437 for ; Fri, 27 Aug 2004 05:05:52 -0700 (PDT) Received: from MPLS-LDN-MS2.macmillan.co.uk (mpls-ldn-ms2.macmillan.co.uk [172.21.0.15]) by smtp-out-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 0B89120C462 for ; Fri, 27 Aug 2004 13:02:28 +0100 (BST) Received: from smtp-in-ldn-01.macmillan.co.uk (unverified) by MPLS-LDN-MS2.macmillan.co.uk (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 27 Aug 2004 07:58:03 +0100 Received: from above.proper.com (above.proper.com [208.184.76.39]) by smtp-in-ldn-01.macmillan.co.uk (Postfix) with ESMTP id 03DCA198134; Fri, 27 Aug 2004 07:58:02 +0100 (BST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6ecsh087781; Thu, 26 Aug 2004 23:40:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R6ecfp087780; Thu, 26 Aug 2004 23:40:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R6ebrT087771 for ; Thu, 26 Aug 2004 23:40:37 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2B9EA7C1EE; Fri, 27 Aug 2004 09:31:09 +0200 (CEST) To: mint@franklinmint.fm Cc: Atom-Syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> Message-ID: Date: Fri, 27 Aug 2004 08:42:33 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412E48B6.3020603@franklinmint.fm> User-Agent: Opera M2/7.60 (Win32, build 7141) List-Archive: List-Unsubscribe: List-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 16:31:50 -0400, Robert Sayre wrote: > I think we're on our twentieth lap here. The only disagreement is from > Mark (anyone else?) on c14n. I'm +1 with Mark on requiring or recommending c14n on publishers (not consumers). -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 08:23:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24504 for ; Fri, 27 Aug 2004 08:23:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCF14q091296; Fri, 27 Aug 2004 05:15:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RCF19C091295; Fri, 27 Aug 2004 05:15:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RCExtN091265 for ; Fri, 27 Aug 2004 05:15:00 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 18411 invoked by uid 65534); 27 Aug 2004 12:14:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.18]) (217.5.201.10) by mail.gmx.net (mp007) with SMTP; 27 Aug 2004 14:14:55 +0200 X-Authenticated: #1915285 Message-ID: <412F25BF.8030408@gmx.de> Date: Fri, 27 Aug 2004 14:14:55 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Wed, 25 Aug 2004 22:23:35 +0200, Julian Reschke > wrote: > >> If consumers compare them as strings anyway, there's no point in >> requiring canonicalization, right? > > > Yes, because if publishers don't canonicalize and normalize, > 'http://EXAMPLE.COM/1231' and 'http://example.com/1231' would be > string-compared as two different entries, regardless of what the > publisher really intended with those URI's. Most likely, the publisher > wanted them to be the same. If he wanted that, he made a mistake. It's better if this mistake has the same consequences in all aggregators, I would think. > If all publishers normalize, canonicalize and do everything in their > power to keep atom:id stable and easy to compare, being an Atom > consumer will be easy. If they don't, being an Atom consumer will be hard. Atom IDs *are* simple to compare if we stick with char-by-char comparison. All recipients will behave exactly the same. Isn't this what interoperability is about? -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 27 08:39:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25593 for ; Fri, 27 Aug 2004 08:39:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCPHfF093995; Fri, 27 Aug 2004 05:25:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RCPHxk093993; Fri, 27 Aug 2004 05:25:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCPHkJ093969; Fri, 27 Aug 2004 05:25:17 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0fn8-0002r8-5Q; Fri, 27 Aug 2004 12:25:14 +0000 Message-ID: <412F282A.1030907@franklinmint.fm> Date: Fri, 27 Aug 2004 08:25:14 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Davis CC: Paul Hoffman / IMC , Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040826233003.81730.qmail@web41207.mail.yahoo.com> <412E7DDD.6070700@internetalchemy.org> <412E8C36.9070605@internetalchemy.org> <412EFFD9.5000508@internetalchemy.org> In-Reply-To: <412EFFD9.5000508@internetalchemy.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > > On 27/08/2004 03:05, Paul Hoffman / IMC wrote: > >> Are you saying it is onerous to create >> http://hostname/date-down-to-subseconds/hash-of-content for those? > > Yes. Show me how to get the current time in XSLT. Pass a parameter to the XSLT Processor. > >> A number of folks on the list have given a few different reasons why >> they really want it, so saying it doesn't solve "the problem it was >> intended to solve" isn't really the issue. If you feel that it doesn't >> solve the problems that folks have listed, that's fine, but you need >> to show that. > > I disagree. Saying it doesn't solve "the problem it was intended to > solve" *is* the issue. I believe you should be asking the ID proponents > to demonstrate how it solves the problem that is is designed to address. Duplication and identification are important. Usenet has IDs. Email has IDs. All that "references", and "in-reply-to" stuff sure is useless... Neither of those technologies are perfect, but yes, IDs help. > I've provided several arguments to the contrary. Yes, you've provided several arguments. They're not very convincing. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Aug 27 09:08:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27030 for ; Fri, 27 Aug 2004 09:08:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCxTmx003228; Fri, 27 Aug 2004 05:59:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RCxTeS003227; Fri, 27 Aug 2004 05:59:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCxTYE003211 for ; Fri, 27 Aug 2004 05:59:29 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 11385 invoked by uid 17064); 27 Aug 2004 12:59:29 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.131.97]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 27 Aug 2004 12:59:29 -0000 In-Reply-To: <20040827030215.49F77171D90@mail.pubsub.com> References: <20040827030215.49F77171D90@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: " " From: Henry Story Subject: Re: ID - wrong solution to the problem? Date: Fri, 27 Aug 2004 14:59:24 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Aug 2004, at 05:00, Bob Wyman wrote: > > > Antone Roundy wrote: >> A solution is to check for duplicate IDs first, and then do some >> kind of comparison between any entries that do have the same ID > Would you mind describing what this "some kind of comparison" might > be? > What comparison can you do that will allow you to detect a malicious > attempt to replace an existing entry? You cannot use the argument that because something can maliciously be misused, that it therefore should not be used. Everything can be misused. A toothbrush can be used to kill someone if properly wielded. A question in return is: would it be impossible to secure this, by eg. using a signature? Henry > If such a comparison can be defined and shown to work, this whole > issue would simply evaporate. > > bob wyman > From owner-atom-syntax@mail.imc.org Fri Aug 27 09:19:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27878 for ; Fri, 27 Aug 2004 09:19:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDBlAH006479; Fri, 27 Aug 2004 06:11:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDBlhk006478; Fri, 27 Aug 2004 06:11:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RDBkew006444 for ; Fri, 27 Aug 2004 06:11:46 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040827131143.20178.qmail@web41207.mail.yahoo.com> Received: from [67.160.86.62] by web41207.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 06:11:43 PDT Date: Fri, 27 Aug 2004 06:11:43 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceIdConstruct To: Julian Reschke , "Asbjørn_Ulsberg" Cc: Atom-Syntax In-Reply-To: <412EE4CC.7000403@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Julian Reschke wrote: > > > > Yes, because if publishers don't canonicalize and > normalize, > > 'http://EXAMPLE.COM/1231' and > 'http://example.com/1231' would be > > string-compared as two different entries, > regardless of what the > > publisher really intended with those URI's. Most > likely, the publisher > > wanted them to be the same. > > Well, that's the publisher's problem. If they want > two IDs to be the > same, they'd better use the same string (as the spec > tells them). +1 > > If all publishers normalize, canonicalize and do > everything in their > > power to keep atom:id stable and easy to compare, > being an Atom > > consumer will be easy. If they don't, being an > Atom consumer will be hard. > > Incorrect. As long as IDs are compared as strings, > and both producers > and consumers are aware of that, there is no issue. > Please don't make > things more complicated than needed. +2 ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Fri Aug 27 09:28:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28335 for ; Fri, 27 Aug 2004 09:28:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDIHkF008358; Fri, 27 Aug 2004 06:18:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDIHxi008357; Fri, 27 Aug 2004 06:18:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDIG5G008318 for ; Fri, 27 Aug 2004 06:18:17 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so427893rnk for ; Fri, 27 Aug 2004 06:18:13 -0700 (PDT) Received: by 10.38.102.54 with SMTP id z54mr2746197rnb; Fri, 27 Aug 2004 06:18:13 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Fri, 27 Aug 2004 06:18:13 -0700 (PDT) Message-ID: <14be96d304082706186c6b8a00@mail.gmail.com> Date: Fri, 27 Aug 2004 09:18:13 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: "Asbjørn Ulsberg" Subject: Re: Feeds MUST have alternate links? Cc: Sam Ruby , Atom-Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <87smabifw7.fsf@nwalsh.com> <412DBD74.9040904@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RDIH5G008350 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 08:48:20 +0200, Asbjørn Ulsberg wrote: > > On Thu, 26 Aug 2004 06:37:40 -0400, Sam Ruby > wrote: > > > Let me point out that the channel link element is required in every > > version of RSS from 0.91 to 1.0 to 2.0. > > ....Which is exactly why I (and others I know of) can't use RSS for many of > the purposes I'd like, but instead hope to be able to use Atom in those > areas. If you're looking for a syndication format that's even looser and has even fewer required elements than RSS, you're in the wrong place. > Many Atom entries and feeds won't have alternate, human readable > (typically HTML) alternatives. If by "many" you mean "vanishingly few", then yes. Otherwise, no. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Fri Aug 27 09:37:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28831 for ; Fri, 27 Aug 2004 09:37:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDO5wW010002; Fri, 27 Aug 2004 06:24:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDO5LH010001; Fri, 27 Aug 2004 06:24:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RDO4Pn009968 for ; Fri, 27 Aug 2004 06:24:04 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040827132401.43472.qmail@web41212.mail.yahoo.com> Received: from [67.160.86.62] by web41212.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 06:24:01 PDT Date: Fri, 27 Aug 2004 06:24:01 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? To: Henry Story , Atom Syntax Cc: " " In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Henry Story wrote: > > You cannot use the argument that because something > can maliciously be > misused, that it therefore should not be used. > > Everything can be misused. A toothbrush can be used > to kill someone if > properly wielded. > > A question in return is: would it be impossible to > secure this, by eg. > using a signature? Exactly. Every technology can be misused. Should blogging web servers & HTML never have been invented because there are hate sites on the Web? Should email and USENET never have been invented because of spam? Should operating systems that could connect to the network never have been envisioned because machines can be hacked? If you start playing this game, then there should be no software industry because every significant class of software can be abused. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Aug 27 09:40:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28931 for ; Fri, 27 Aug 2004 09:40:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDVej0012186; Fri, 27 Aug 2004 06:31:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDVeit012185; Fri, 27 Aug 2004 06:31:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RDVdl8012158 for ; Fri, 27 Aug 2004 06:31:39 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040827133137.79617.qmail@web41202.mail.yahoo.com> Received: from [67.160.86.62] by web41202.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 06:31:36 PDT Date: Fri, 27 Aug 2004 06:31:36 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? To: Ian Davis Cc: atom-syntax@imc.org In-Reply-To: <412EF670.2070807@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > > It's just as theoretical as the notion that unique > IDs are going to > prevent duplicates. Demonstrate that and then my > scenario above becomes > rather more concrete. It's as theoretical as http://www.rssbandit.org I currently use links as unique IDs to prevent duplicates among other things. The problem is that links are not good enough for a variety of reasons that have been discussed ad nauseum on this list. Similarly a combination of link + entry data is not good enough. Practically every aggregator author I am aware of does something similar. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Fri Aug 27 09:56:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29859 for ; Fri, 27 Aug 2004 09:56:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDk1pS015887; Fri, 27 Aug 2004 06:46:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDk1ae015886; Fri, 27 Aug 2004 06:46:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RDjYId015822 for ; Fri, 27 Aug 2004 06:45:58 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 90963 invoked from network); 27 Aug 2004 13:45:33 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 13:45:33 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412F3B06.2090806@internetalchemy.org> Date: Fri, 27 Aug 2004 14:45:42 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Sam Ruby , Atom-Syntax Subject: Re: Feeds MUST have alternate links? References: <87smabifw7.fsf@nwalsh.com> <412DBD74.9040904@intertwingly.net> <14be96d304082706186c6b8a00@mail.gmail.com> In-Reply-To: <14be96d304082706186c6b8a00@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 14:18, Mark Pilgrim wrote: > >>Many Atom entries and feeds won't have alternate, human readable >>(typically HTML) alternatives. > > > If by "many" you mean "vanishingly few", then yes. Otherwise, no. > What do you suggest feeds like the following should do? http://offog.org/changes.rss Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 09:56:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29895 for ; Fri, 27 Aug 2004 09:56:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDkawE016018; Fri, 27 Aug 2004 06:46:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDkaRg016017; Fri, 27 Aug 2004 06:46:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDkZZM016005 for ; Fri, 27 Aug 2004 06:46:35 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7RDkZT04950 for ; Fri, 27 Aug 2004 16:46:35 +0300 (EET DST) X-Scanned: Fri, 27 Aug 2004 16:46:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7RDk7kT030894 for ; Fri, 27 Aug 2004 16:46:07 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00hD4feR; Fri, 27 Aug 2004 16:46:05 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7RDk4u03654 for ; Fri, 27 Aug 2004 16:46:04 +0300 (EET DST) Received: from [172.21.60.114] ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 27 Aug 2004 16:45:58 +0300 Message-ID: <412F3B15.2070009@nokia.com> Date: Fri, 27 Aug 2004 16:45:57 +0300 From: Janne Jalkanen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040619 X-Accept-Language: fi, en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: Link requirements [was : Can atom be Del.icio.us?] References: <81395121-F6CA-11D8-AFC5-003065EA6144@geckotribe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2004 13:45:58.0560 (UTC) FILETIME=[2EE06200:01C48C3C] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>> (1) Each atom:entry element must have one or more link elements >>> associated with it. >> >> >> This fits current syndication usage as far as I'm aware. > > > Syndication of ordinary blogs, yes. Syndication of absolutely all > other types of resources on the web; no. Yeah. The JSPWiki RSS/RDF feed currently has the latest diff of the page as the content of the entry. This means that I already have a slight headache for thinking what my unique atom:id is going to be for them - after all, they are generated dynamically (no, I don't want to inflate a database with a wiki RecentChanges list). The ID must contain references to the different version numbers, etc... I was thinking of offering Atom feeds like "all differences from the last 24 hours" and "all diffs from the last week" or so, and I don't necessarily want to provide an HTML version of all the possible variants, as I can think of some uses which might be machine-readable only (like providing diffs to wiki pages which are consumed by a bot which keeps a duplicate of the wiki somewhere else, applying the diffs as they come along... This might also mean that one might want to get an Atom feed with a timestamp: "please provide me changes from date XXYYZZHHMM onwards" using either some custom header or GET parameter trickery.) I just think a syndication format should be able to stand on its own, without any references to external resources, that's all. It would make Atom more attractive to machine-to-machine communication. /Janne From owner-atom-syntax@mail.imc.org Fri Aug 27 09:56:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29919 for ; Fri, 27 Aug 2004 09:56:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDmYca016326; Fri, 27 Aug 2004 06:48:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDmYqD016325; Fri, 27 Aug 2004 06:48:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RDmX8N016319 for ; Fri, 27 Aug 2004 06:48:33 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 92948 invoked from network); 27 Aug 2004 13:48:35 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 13:48:35 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412F3BBC.4000202@internetalchemy.org> Date: Fri, 27 Aug 2004 14:48:44 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <20040827133137.79617.qmail@web41202.mail.yahoo.com> In-Reply-To: <20040827133137.79617.qmail@web41202.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 14:31, Dare Obasanjo wrote: > I currently use links as unique IDs to prevent > duplicates among other things. The problem is that > links are not good enough for a variety of reasons > that have been discussed ad nauseum on this list. > Similarly a combination of link + entry data is not > good enough. > > Practically every aggregator author I am aware of does > something similar. You still haven't demonstrated that IDs are going to solve the duplicates problem. Your response just reiterates what we already know - it's hard to detect duplicates using the content the publisher supplies. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 10:09:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00975 for ; Fri, 27 Aug 2004 10:09:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RE007g018719; Fri, 27 Aug 2004 07:00:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RE00ms018718; Fri, 27 Aug 2004 07:00:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RDxxMQ018699 for ; Fri, 27 Aug 2004 06:59:59 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 2026 invoked from network); 27 Aug 2004 13:59:59 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 13:59:59 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412F3E69.30301@internetalchemy.org> Date: Fri, 27 Aug 2004 15:00:09 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Henry Story , Atom Syntax Subject: Re: ID - wrong solution to the problem? References: <20040827132401.43472.qmail@web41212.mail.yahoo.com> In-Reply-To: <20040827132401.43472.qmail@web41212.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 14:24, Dare Obasanjo wrote: > Exactly. Every technology can be misused. Should > blogging web servers & HTML never have been invented > because there are hate sites on the Web? Should email > and USENET never have been invented because of spam? > Should operating systems that could connect to the > network never have been envisioned because machines > can be hacked? > > If you start playing this game, then there should be > no software industry because every significant class > of software can be abused. This form of argument will not cut it in the RFC process. The RFC will have to state the risks and describe how these are avoided or mitigated. I suggested a form of denial of service made possible by mandating producer generated unique IDs. We need to work out some method of mitigating the risk, e.g. "If the normal behaviour of the client is to hide duplicate entries then clients SHOULD report the number of duplicate entries found in a feed and SHOULD provide the user with a mechanism for displaying them. The client MAY display the conflicting entries from other feeds." Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 10:14:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01561 for ; Fri, 27 Aug 2004 10:14:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RE7AhS020274; Fri, 27 Aug 2004 07:07:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RE7AtZ020273; Fri, 27 Aug 2004 07:07:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RE79Mm020267 for ; Fri, 27 Aug 2004 07:07:09 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0hNk-0004TJ-SR; Fri, 27 Aug 2004 14:07:09 +0000 Message-ID: <412F400C.5030902@franklinmint.fm> Date: Fri, 27 Aug 2004 10:07:08 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Davis CC: Dare Obasanjo , atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <20040827133137.79617.qmail@web41202.mail.yahoo.com> <412F3BBC.4000202@internetalchemy.org> In-Reply-To: <412F3BBC.4000202@internetalchemy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > > On 27/08/2004 14:31, Dare Obasanjo wrote: > >> I currently use links as unique IDs to prevent >> duplicates among other things. The problem is that >> links are not good enough for a variety of reasons >> that have been discussed ad nauseum on this list. >> Similarly a combination of link + entry data is not >> good enough. >> Practically every aggregator author I am aware of does >> something similar. > > > You still haven't demonstrated that IDs are going to solve the > duplicates problem. Your response just reiterates what we already know - > it's hard to detect duplicates using the content the publisher supplies. If you keep writing this stuff, you may succeed in putting us all to sleep. Here are some interesting articles: How does duplicate detection work?[0] How does Usenet handle News? [1] Robert Sayre [0] http://blogs.msdn.com/exchange/archive/2004/07/14/183132.aspx [1] http://www.faqs.org/docs/linux_network/x-087-2-news.algorithm.html From owner-atom-syntax@mail.imc.org Fri Aug 27 10:19:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02301 for ; Fri, 27 Aug 2004 10:19:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RED2f4021931; Fri, 27 Aug 2004 07:13:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RED2Wc021930; Fri, 27 Aug 2004 07:13:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41201.mail.yahoo.com (web41201.mail.yahoo.com [66.218.93.34]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RED2ih021901 for ; Fri, 27 Aug 2004 07:13:02 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040827141259.86201.qmail@web41201.mail.yahoo.com> Received: from [67.160.86.62] by web41201.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 07:12:59 PDT Date: Fri, 27 Aug 2004 07:12:59 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? To: Ian Davis Cc: atom-syntax@imc.org In-Reply-To: <412F3BBC.4000202@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > > You still haven't demonstrated that IDs are going to > solve the > duplicates problem. Your response just reiterates > what we already know - > it's hard to detect duplicates using the content > the publisher supplies. My mistake, I thought it was painfully obvious. Here goes Scenario 1: A client fetches a feed which contains 10 items on Monday. The client fetches the same feed on Tuesday and it still has 10 items but 3 of them new entries. How does the client tell which of the 10 fetched on Tuesday the user has seen and which ones the user would consider as 'new'? How IDs Solve This Problem: The aggregator checks the ID of items fetched on Tuesday with those on Monday. That way it determines only 3 are new. EVERY aggregator that distinguishes between new and prevuiously seen items has code like this today. Scenario 2: Some items have relationships between them such as the parent-child relationships between USENET posts or comments in response to an item. How does the aggregator know which entries are related? How IDs Solve This Problem: The subordinate items can reference the IDs of items they are related to. As has been mentioned email and USENET work like this today and given that there are Atom feeds of USENET and mailing lists it seems Atom should support this scenario. Scenario 3: Feeds containing results from multiple feeds such as search engines (Feedster) need to be able to determine when they are returning the same result fetched from multiple feeds so they don't show users duplicate entries. How IDs Solve This Problem: If an entry has a unique ID across the multiple feeds it belongs in then Feedster can use a combination of the ID + updated date to determine the single entry to show the user. There is a potential for malicious hijackings of sites with this approach but the problem already exists in RSS today and I've never actually heard of it happening. Scenario 4: An entry can show up in multiple feeds at once. For example entries from my work blog an be seen in the feeds for http://blogs.msdn.com/dareobasanjo, http://blogs.msdn.com or http://weblogs.asp.net . It is a conceivable for a user to be subscribed to both the individual feeds and aggregated feeds in which case they see duplicate entries [once in the aggregate feed and once in the individual feed]. The main problem being when they read an item in one place it isn't marked as read in the other feed even though it is the same item How IDs Solve This Problem: If the item used the same ID in all feeds it appeared in then the aggregator could mark it as read in all feeds it appears in once it is read in any feed. There are more but I'll let you chew on these for a while. :) ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Aug 27 10:20:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02366 for ; Fri, 27 Aug 2004 10:20:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REBLTq021455; Fri, 27 Aug 2004 07:11:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7REBLjn021453; Fri, 27 Aug 2004 07:11:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7REBK7C021440 for ; Fri, 27 Aug 2004 07:11:20 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 10216 invoked from network); 27 Aug 2004 14:11:21 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 14:11:21 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412F4113.6080003@internetalchemy.org> Date: Fri, 27 Aug 2004 15:11:31 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Dare Obasanjo , atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <20040827133137.79617.qmail@web41202.mail.yahoo.com> <412F3BBC.4000202@internetalchemy.org> <412F400C.5030902@franklinmint.fm> In-Reply-To: <412F400C.5030902@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27/08/2004 15:07, Robert Sayre wrote: > [0] http://blogs.msdn.com/exchange/archive/2004/07/14/183132.aspx Thanks, very informative: "We would have liked to do duplicate detection based solely on the Internet Message Id but there are several not-to-be named applications out there that use the same Internet Message Id on all their messages." Hmmm. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 10:28:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03110 for ; Fri, 27 Aug 2004 10:28:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REK4rb024766; Fri, 27 Aug 2004 07:20:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7REK4Yo024765; Fri, 27 Aug 2004 07:20:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mirapoint1.tis.cwru.edu (IDENT:mirapoint@mirapoint1.TIS.CWRU.Edu [129.22.104.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REK4MC024741 for ; Fri, 27 Aug 2004 07:20:04 -0700 (PDT) (envelope-from jms18@cwru.edu) Received: from [129.22.114.48] (magonia.ITS.CWRU.Edu [129.22.114.48]) by mirapoint1.tis.cwru.edu (MOS 3.4.3-CR) with ESMTP id CJR38949 (AUTH jms18); Fri, 27 Aug 2004 10:18:46 -0400 (EDT) Message-ID: <412F42D1.5060103@cwru.edu> Date: Fri, 27 Aug 2004 10:18:57 -0400 From: Jeremy Smith User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <476b71e80408270456f06f3f@mail.gmail.com> In-Reply-To: <476b71e80408270456f06f3f@mail.gmail.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030106050804030203090708" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms030106050804030203090708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit grayrest wrote: >On Fri, 27 Aug 2004 08:42:33 +0200, Asbjørn Ulsberg > wrote: > > >>>I think we're on our twentieth lap here. The only disagreement is from >>>Mark (anyone else?) on c14n. >>> >>> >>I'm +1 with Mark on requiring or recommending c14n on publishers (not >>consumers). >> >> > >I'm not sure if my vote counts, but I'm +1 on c14n for publishers and >not consumers. It's not that difficult to normalize your own url and >simplifies client implementation. > > > +1 for c14n on publishers. --------------ms030106050804030203090708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII3TCC AskwggIyoAMCAQICAwuUFzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMTI3MTczNjAyWhcNMDUwMTI2MTczNjAy WjBAMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR0wGwYJKoZIhvcNAQkBFg5q bXMxOEBjd3J1LmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPf8o5eHqNJc 9J/QGkeJl8ZkhHrSE7B2aNu3uZ58dVbu4fCrZS19yqbkBku1dwCvu6rmdk77yJDDyo8XW6k2 IUOgVNtUcwd+OPv7xy2vt0KhM/X8UioVo7uKH4Al85tl82Q5+u/8sF5meFUB7WqrdkxdvTry 3Dy72D3kU0HOaRF1ZxgYzx0+EhBxTn7NovNM5ssS82sS+nGIkxildehWM77SbpwBa2/aVUUu G/M7LUF9aA1JIZ2mVaEpCD/CFXj94bkqDEBTprMN53qFcuCvzf1wjaYKYI1gRHygeBDEgiLQ Vdt8S6ah80gwfRdU67ureZCPauNhPh5Z8bioB+oGw7sCAwEAAaMrMCkwGQYDVR0RBBIwEIEO am1zMThAY3dydS5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC9ORgJ8o22 9pge8784ly/Rkt2twNDH2YSi7VtDBykSqehza6efNUilYF1G6AbyK285QkkjyR5hiz8RGdrW WC3Qx+OyJpptqK6rVVsFRjpQA+6U5+ZZj2Bo3AxusdfTr3rDqoulruA7auxsst7agq4gOlCw y3srzsNw0Zekvu/aVDCCAskwggIyoAMCAQICAwuUFzANBgkqhkiG9w0BAQQFADBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMTI3MTczNjAy WhcNMDUwMTI2MTczNjAyWjBAMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR0w GwYJKoZIhvcNAQkBFg5qbXMxOEBjd3J1LmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAPf8o5eHqNJc9J/QGkeJl8ZkhHrSE7B2aNu3uZ58dVbu4fCrZS19yqbkBku1dwCv u6rmdk77yJDDyo8XW6k2IUOgVNtUcwd+OPv7xy2vt0KhM/X8UioVo7uKH4Al85tl82Q5+u/8 sF5meFUB7WqrdkxdvTry3Dy72D3kU0HOaRF1ZxgYzx0+EhBxTn7NovNM5ssS82sS+nGIkxil dehWM77SbpwBa2/aVUUuG/M7LUF9aA1JIZ2mVaEpCD/CFXj94bkqDEBTprMN53qFcuCvzf1w jaYKYI1gRHygeBDEgiLQVdt8S6ah80gwfRdU67ureZCPauNhPh5Z8bioB+oGw7sCAwEAAaMr MCkwGQYDVR0RBBIwEIEOam1zMThAY3dydS5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQC9ORgJ8o229pge8784ly/Rkt2twNDH2YSi7VtDBykSqehza6efNUilYF1G6Aby K285QkkjyR5hiz8RGdrWWC3Qx+OyJpptqK6rVVsFRjpQA+6U5+ZZj2Bo3AxusdfTr3rDqoul ruA7auxsst7agq4gOlCwy3srzsNw0Zekvu/aVDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC5QXMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyNzE0MTg1N1owIwYJKoZIhvcNAQkEMRYEFCIO2VYmtpc97ass f1qqWPZn2OKoMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFr MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLlBcw egYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDC5QXMA0GCSqGSIb3DQEBAQUABIIBANKseXc5wrfpj2LW+Mdd+NYIzg6e lrq1V+MoeXni9Lc6NXh8KeBQGfRHxFvdtOQALaqBjKo5v0JqgC8dWlTlXNinqno2wiLQ1jaV FfCqZ1pdt61jxC5M3fRbVDBtHMd2kdI5U2c7tKkL67ZskDyWkcdsFaBdtkLhdqBfr6KCqxw5 KxDOtmzxG6GDyd3mQPPi5+dhfwDsyI4DF/q4tOtOYtHM6kaqtUrMn6FTORSzmYt4UMizAq3+ LeNDzOnJmthoY3w/0ho6XBz4JytZapM8E74AME6odXOh+nyyza8Q6IuxBMoYFFDKfsC5FO1c WiFY5FgRC3Z/asjKixOxli5jCZQAAAAAAAA= --------------ms030106050804030203090708-- From owner-atom-syntax@mail.imc.org Fri Aug 27 10:29:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03214 for ; Fri, 27 Aug 2004 10:29:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REEHCw022408; Fri, 27 Aug 2004 07:14:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7REEHQq022407; Fri, 27 Aug 2004 07:14:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REEGFo022399 for ; Fri, 27 Aug 2004 07:14:16 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0hUe-0005LK-3Q; Fri, 27 Aug 2004 14:14:16 +0000 Message-ID: <412F41B9.4040304@franklinmint.fm> Date: Fri, 27 Aug 2004 10:14:17 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Davis CC: Dare Obasanjo , atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <20040827133137.79617.qmail@web41202.mail.yahoo.com> <412F3BBC.4000202@internetalchemy.org> <412F400C.5030902@franklinmint.fm> <412F4113.6080003@internetalchemy.org> In-Reply-To: <412F4113.6080003@internetalchemy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis wrote: > On 27/08/2004 15:07, Robert Sayre wrote: > >> [0] http://blogs.msdn.com/exchange/archive/2004/07/14/183132.aspx > > Thanks, very informative: > > "We would have liked to do duplicate detection based solely on the > Internet Message Id but there are several not-to-be named applications > out there that use the same Internet Message Id on all their messages." > Thanks for the out-of-context quote. There's no concept of a duplicate without identity. Welcome to my killfile. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Aug 27 10:29:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03232 for ; Fri, 27 Aug 2004 10:29:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REIUYM024198; Fri, 27 Aug 2004 07:18:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7REIUMs024197; Fri, 27 Aug 2004 07:18:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7REIUR9024161 for ; Fri, 27 Aug 2004 07:18:30 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040827141827.33774.qmail@web41207.mail.yahoo.com> Received: from [67.160.86.62] by web41207.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 07:18:27 PDT Date: Fri, 27 Aug 2004 07:18:27 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? To: Ian Davis , mint@franklinmint.fm Cc: Dare Obasanjo , atom-syntax@imc.org In-Reply-To: <412F4113.6080003@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Ian Davis wrote: > http://blogs.msdn.com/exchange/archive/2004/07/14/183132.aspx > Thanks, very informative: > > "We would have liked to do duplicate detection based > solely on the > Internet Message Id but there are several not-to-be > named applications > out there that use the same Internet Message Id on > all their messages." Your point? Morons will implement the spec incorrectly. No matter what technique you come up with there'll be some broken application that gets it wrong. The question is how easy is it to get it wrong and how hard is it to get right? Seriously, you are undermining your credibility to more you continue to post. If you have nothing constructive to add besides randomization and noise perhaps you should sit out of this discussion. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Aug 27 10:32:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03419 for ; Fri, 27 Aug 2004 10:32:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RELC79025226; Fri, 27 Aug 2004 07:21:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RELCUK025225; Fri, 27 Aug 2004 07:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RELC9i025214 for ; Fri, 27 Aug 2004 07:21:12 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 17117 invoked from network); 27 Aug 2004 14:21:13 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 27 Aug 2004 14:21:13 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <412F4363.2000507@internetalchemy.org> Date: Fri, 27 Aug 2004 15:21:23 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? References: <20040827141259.86201.qmail@web41201.mail.yahoo.com> In-Reply-To: <20040827141259.86201.qmail@web41201.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What about the problems here: http://www.imc.org/atom-syntax/mail-archive/msg08986.html Ian On 27/08/2004 15:12, Dare Obasanjo wrote: > > --- Ian Davis wrote: > >>You still haven't demonstrated that IDs are going to >>solve the >>duplicates problem. Your response just reiterates >>what we already know - >> it's hard to detect duplicates using the content >>the publisher supplies. > > > My mistake, I thought it was painfully obvious. Here > goes > > Scenario 1: A client fetches a feed which contains 10 > items on Monday. The client fetches the same feed on > Tuesday and it still has 10 items but 3 of them new > entries. How does the client tell which of the 10 > fetched on Tuesday the user has seen and which ones > the user would consider as 'new'? > > How IDs Solve This Problem: The aggregator checks the > ID of items fetched on Tuesday with those on Monday. > That way it determines only 3 are new. EVERY > aggregator that distinguishes between new and > prevuiously seen items has code like this today. > > Scenario 2: Some items have relationships between them > such as the parent-child relationships between USENET > posts or comments in response to an item. How does the > aggregator know which entries are related? > > How IDs Solve This Problem: The subordinate items can > reference the IDs of items they are related to. As has > been mentioned email and USENET work like this today > and given that there are Atom feeds of USENET and > mailing lists it seems Atom should support this > scenario. > > Scenario 3: Feeds containing results from multiple > feeds such as search engines (Feedster) need to be > able to determine when they are returning the same > result fetched from multiple feeds so they don't show > users duplicate entries. > > How IDs Solve This Problem: If an entry has a unique > ID across the multiple feeds it belongs in then > Feedster can use a combination of the ID + updated > date to determine the single entry to show the user. > There is a potential for malicious hijackings of sites > with this approach but the problem already exists in > RSS today and I've never actually heard of it > happening. > > Scenario 4: An entry can show up in multiple feeds at > once. For example entries from my work blog an be seen > in the feeds for http://blogs.msdn.com/dareobasanjo, > http://blogs.msdn.com or http://weblogs.asp.net . It > is a conceivable for a user to be subscribed to both > the individual feeds and aggregated feeds in which > case they see duplicate entries [once in the aggregate > feed and once in the individual feed]. The main > problem being when they read an item in one place it > isn't marked as read in the other feed even though it > is the same item > > How IDs Solve This Problem: If the item used the same > ID in all feeds it appeared in then the aggregator > could mark it as read in all feeds it appears in once > it is read in any feed. > > > There are more but I'll let you chew on these for a > while. :) > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 > I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > > > From owner-atom-syntax@mail.imc.org Fri Aug 27 10:32:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03431 for ; Fri, 27 Aug 2004 10:32:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REO8WS026316; Fri, 27 Aug 2004 07:24:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7REO8vf026315; Fri, 27 Aug 2004 07:24:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7REO74a026279 for ; Fri, 27 Aug 2004 07:24:07 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040827142405.91188.qmail@web41202.mail.yahoo.com> Received: from [67.160.86.62] by web41202.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 07:24:05 PDT Date: Fri, 27 Aug 2004 07:24:05 -0700 (PDT) From: Dare Obasanjo Subject: Re: ID - wrong solution to the problem? To: Ian Davis Cc: atom-syntax@imc.org In-Reply-To: <412F4363.2000507@internetalchemy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have already responded to that thread. It seems you are just time wasting troll. *kerplunk* - welcome to the killfile. There goes 30 minutes of my life I'm not getting back. --- Ian Davis wrote: > What about the problems here: > > http://www.imc.org/atom-syntax/mail-archive/msg08986.html > > Ian > > On 27/08/2004 15:12, Dare Obasanjo wrote: > > > > > --- Ian Davis wrote: > > > >>You still haven't demonstrated that IDs are going > to > >>solve the > >>duplicates problem. Your response just reiterates > >>what we already know - > >> it's hard to detect duplicates using the content > >>the publisher supplies. > > > > > > My mistake, I thought it was painfully obvious. > Here > > goes > > > > Scenario 1: A client fetches a feed which contains > 10 > > items on Monday. The client fetches the same feed > on > > Tuesday and it still has 10 items but 3 of them > new > > entries. How does the client tell which of the 10 > > fetched on Tuesday the user has seen and which > ones > > the user would consider as 'new'? > > > > How IDs Solve This Problem: The aggregator checks > the > > ID of items fetched on Tuesday with those on > Monday. > > That way it determines only 3 are new. EVERY > > aggregator that distinguishes between new and > > prevuiously seen items has code like this today. > > > > Scenario 2: Some items have relationships between > them > > such as the parent-child relationships between > USENET > > posts or comments in response to an item. How does > the > > aggregator know which entries are related? > > > > How IDs Solve This Problem: The subordinate items > can > > reference the IDs of items they are related to. As > has > > been mentioned email and USENET work like this > today > > and given that there are Atom feeds of USENET and > > mailing lists it seems Atom should support this > > scenario. > > > > Scenario 3: Feeds containing results from multiple > > feeds such as search engines (Feedster) need to be > > able to determine when they are returning the same > > result fetched from multiple feeds so they don't > show > > users duplicate entries. > > > > How IDs Solve This Problem: If an entry has a > unique > > ID across the multiple feeds it belongs in then > > Feedster can use a combination of the ID + updated > > date to determine the single entry to show the > user. > > There is a potential for malicious hijackings of > sites > > with this approach but the problem already exists > in > > RSS today and I've never actually heard of it > > happening. > > > > Scenario 4: An entry can show up in multiple feeds > at > > once. For example entries from my work blog an be > seen > > in the feeds for > http://blogs.msdn.com/dareobasanjo, > > http://blogs.msdn.com or http://weblogs.asp.net . > It > > is a conceivable for a user to be subscribed to > both > > the individual feeds and aggregated feeds in which > > case they see duplicate entries [once in the > aggregate > > feed and once in the individual feed]. The main > > problem being when they read an item in one place > it > > isn't marked as read in the other feed even though > it > > is the same item > > > > How IDs Solve This Problem: If the item used the > same > > ID in all feeds it appeared in then the aggregator > > could mark it as read in all feeds it appears in > once > > it is read in any feed. > > > > > > There are more but I'll let you chew on these for > a > > while. :) > > > > ===== > > THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 > > I will keep a special cache of low-tech weapons > and train my troops in their use. That way -- even > if the heroes manage to neutralize my power > generator and/or render the standard-issue energy > weapons useless -- my troops will not be overrun by > a handful of savages armed with spears and rocks. > > > > > > > > __________________________________ > > Do you Yahoo!? > > New and Improved Yahoo! Mail - Send 10MB messages! > > http://promotions.yahoo.com/new_mail > > > > > > > > ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Aug 27 10:32:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03490 for ; Fri, 27 Aug 2004 10:32:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REMnbR025818; Fri, 27 Aug 2004 07:22:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7REMnFM025817; Fri, 27 Aug 2004 07:22:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REMlmE025804 for ; Fri, 27 Aug 2004 07:22:48 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 28 Aug 2004 00:29:49 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 28 Aug 2004 00:22:33 +1000 Subject: ASIS&T Bulletin: Emerging Content Requirements for News Products From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This just out ... might be interesting reading for the weekend. > Emerging Content Requirements for News Products > by Howard Williams > http://www.asis.org/Bulletin/Aug-04/williams.html > The current trend toward media convergence has placed new demands on > traditional print news providers. Having adapted to the new media environment > in several ways, not the least of them being through expansion into the online > arena, these same news providers are also under increased economic pressure to > identify new sources of revenue. This problem is intensified by the loss of > readership that has impacted their traditional print products. Risks inherent > in the new media environment, however, also carry with them opportunities for > generating new and different types of news products. These products reflect > many of the current trends in online content production, presentation and > delivery, including, for example, the use of multiple delivery channels, > content aggregation and syndication services, personalization based on reader > profiles, advanced search-and-retrieval capabilities and new design approaches > for Web-based presentation. We can expect to see these capabilities extended > and leveraged by news and other content providers as they create increasingly > differentiated products, appealing to consumers with a diversity of needs and > interests. At the same time, the environments in which these products are > created will likely be based on new content production models, characterized > by new value chains and the increased exploitation of value through > multipurposing of content. and it goes on for quite a bit more. e. From owner-atom-syntax@mail.imc.org Fri Aug 27 10:53:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05265 for ; Fri, 27 Aug 2004 10:53:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REhdDi031731; Fri, 27 Aug 2004 07:43:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7REhd1L031730; Fri, 27 Aug 2004 07:43:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REhcR1031723 for ; Fri, 27 Aug 2004 07:43:39 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7REhgMa012896; Fri, 27 Aug 2004 10:43:42 -0400 Message-ID: <412F4898.1070403@intertwingly.net> Date: Fri, 27 Aug 2004 10:43:36 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Joe Hildebrand'" , atom-syntax@imc.org Subject: Re: Transporting Atom Notifications over the XMLPP References: <200408270205.BOS94144@ms8.netsolmail.com> In-Reply-To: <200408270205.BOS94144@ms8.netsolmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > So, please, understand that atom:id is application specific data and > should not be confused with XMPP or JEP-0060 channel specific data. The > layering here is important to maintain. I am quite content with leaving this as: the spec as currently written needs to provide some guidance here; otherwise interoperability will suffer as the consequences of the available choices are not obvious. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Aug 27 10:59:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06014 for ; Fri, 27 Aug 2004 10:59:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REnoZf032385; Fri, 27 Aug 2004 07:49:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7REno3a032384; Fri, 27 Aug 2004 07:49:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7REnnkT032377 for ; Fri, 27 Aug 2004 07:49:49 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 96284 invoked by uid 17064); 27 Aug 2004 14:49:52 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.131.97]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 27 Aug 2004 14:49:52 -0000 In-Reply-To: <412F4363.2000507@internetalchemy.org> References: <20040827141259.86201.qmail@web41201.mail.yahoo.com> <412F4363.2000507@internetalchemy.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56A4A704-F838-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Ian Davis From: Henry Story Subject: Re: ID - wrong solution to the problem? Date: Fri, 27 Aug 2004 16:49:46 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As a side note I have a Atom-OWL model of Atom at: http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html I find the ID tag (represented as an EntryID class) very useful, and it works very nicely with an EntryVersion class. There is a very nice mapping to be made from a simple Entry class to a EntryID that contains all the changes made to an entry over time. Henry On 27 Aug 2004, at 16:21, Ian Davis wrote: > > What about the problems here: > > http://www.imc.org/atom-syntax/mail-archive/msg08986.html > > Ian > > On 27/08/2004 15:12, Dare Obasanjo wrote: > From owner-atom-syntax@mail.imc.org Fri Aug 27 11:24:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09264 for ; Fri, 27 Aug 2004 11:24:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFG4Pj034857; Fri, 27 Aug 2004 08:16:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RFG4R1034856; Fri, 27 Aug 2004 08:16:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFG3aX034845 for ; Fri, 27 Aug 2004 08:16:03 -0700 (PDT) (envelope-from hildjj@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so412252rnk for ; Fri, 27 Aug 2004 08:16:03 -0700 (PDT) Received: by 10.38.209.48 with SMTP id h48mr1590775rng; Fri, 27 Aug 2004 08:16:02 -0700 (PDT) Received: by 10.38.15.47 with HTTP; Fri, 27 Aug 2004 08:16:02 -0700 (PDT) Message-ID: <82777bea040827081643427fa3@mail.gmail.com> Date: Fri, 27 Aug 2004 09:16:02 -0600 From: Joe Hildebrand Reply-To: Joe Hildebrand To: Sam Ruby Subject: Re: Transporting Atom Notifications over the XMLPP Cc: bob@wyman.us, atom-syntax@imc.org In-Reply-To: <412F4898.1070403@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408270205.BOS94144@ms8.netsolmail.com> <412F4898.1070403@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just to clarify, you're talking about leaving the -00 draft alone? I'd be ok with adding a suggestion for how to generate pub/sub id's that was non-normative. BTW, I don't care what the separator character is. Since this ID isn't a URI, it could even use a space as a separator. Maybe that would be the best bet. On Fri, 27 Aug 2004 10:43:36 -0400, Sam Ruby wrote: > Bob Wyman wrote: > > > So, please, understand that atom:id is application specific data and > > should not be confused with XMPP or JEP-0060 channel specific data. The > > layering here is important to maintain. > > I am quite content with leaving this as: the spec as currently written > needs to provide some guidance here; otherwise interoperability will > suffer as the consequences of the available choices are not obvious. > > - Sam Ruby > > -- Joe Hildebrand From owner-atom-syntax@mail.imc.org Fri Aug 27 11:49:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11168 for ; Fri, 27 Aug 2004 11:49:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFfUE0037429; Fri, 27 Aug 2004 08:41:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RFfUDt037428; Fri, 27 Aug 2004 08:41:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFfUoL037409 for ; Fri, 27 Aug 2004 08:41:30 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0ir4-00023E-0h; Fri, 27 Aug 2004 15:41:30 +0000 Message-ID: <412F562B.5080601@franklinmint.fm> Date: Fri, 27 Aug 2004 11:41:31 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Janne Jalkanen CC: Atom-Syntax Subject: Re: Link requirements [was : Can atom be Del.icio.us?] References: <81395121-F6CA-11D8-AFC5-003065EA6144@geckotribe.com> <412F3B15.2070009@nokia.com> In-Reply-To: <412F3B15.2070009@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Janne Jalkanen wrote: > > I just think a syndication format should be able to stand on its own, > without any references to external resources, that's all. It would make > Atom more attractive to machine-to-machine communication. > Take a look at PaceLinkDelicious. Currently, it requires "alternate". I could see requiring either "about" or "alternate", but not omitting both. After all, we're defining a format for syndication of Web resources[0]. Robert Sayre [0] http://www.ietf.org/html.charters/atompub-charter.html From owner-atom-syntax@mail.imc.org Fri Aug 27 11:50:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11201 for ; Fri, 27 Aug 2004 11:50:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFek6b037334; Fri, 27 Aug 2004 08:40:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RFekhs037333; Fri, 27 Aug 2004 08:40:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFejip037327 for ; Fri, 27 Aug 2004 08:40:45 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7RFeq6f015335; Fri, 27 Aug 2004 11:40:53 -0400 Message-ID: <412F55FE.1080508@intertwingly.net> Date: Fri, 27 Aug 2004 11:40:46 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: bob@wyman.us, atom-syntax@imc.org Subject: Re: Transporting Atom Notifications over the XMLPP References: <200408270205.BOS94144@ms8.netsolmail.com> <412F4898.1070403@intertwingly.net> <82777bea040827081643427fa3@mail.gmail.com> In-Reply-To: <82777bea040827081643427fa3@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > Just to clarify, you're talking about leaving the -00 draft alone? No, I think the spec as currently written is dangerously ambiguous. If I am reading this correctly, the current consensus is that these two concepts are orthogonal. Just to be clear: this is a clear reversal of "No need for yet another GUID-y thing in the world."... which was an honest and understandable opinion; the danger is that too many people will initially form a similar opinion, and some may act upon it. > I'd be ok with adding a suggestion for how to generate pub/sub id's > that was non-normative. > > BTW, I don't care what the separator character is. Since this ID > isn't a URI, it could even use a space as a separator. Maybe that > would be the best bet. I'd recommend against issuing a specific syntax recommendation. People would be too tempted to try to parse the id. - - - I don't yet understand the intended mapping between a feed document and a Jabber node. If each feed is intended to be a separate node, then I don't see the problem with atom:id being the feed ItemId. If a given node can represent multiple feeds, then there is a clear problem that is easy to spell out: the situation where a given entry is syndicated in multiple feeds processed by a single node. Atom would require the atom:id to be the same in each case, Jabber would require the ItemId to differ. As a fan of informative text, examples, and even the occasional judicious use of repetition, I would suggest an informative note which spells out the scenario above. > On Fri, 27 Aug 2004 10:43:36 -0400, Sam Ruby wrote: > >>Bob Wyman wrote: >> >>> So, please, understand that atom:id is application specific data and >>>should not be confused with XMPP or JEP-0060 channel specific data. The >>>layering here is important to maintain. >> >>I am quite content with leaving this as: the spec as currently written >>needs to provide some guidance here; otherwise interoperability will >>suffer as the consequences of the available choices are not obvious. >> >>- Sam Ruby From owner-atom-syntax@mail.imc.org Fri Aug 27 12:03:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11960 for ; Fri, 27 Aug 2004 12:03:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFsfMX038403; Fri, 27 Aug 2004 08:54:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RFsfDC038402; Fri, 27 Aug 2004 08:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RFsfmV038392 for ; Fri, 27 Aug 2004 08:54:41 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc12) with SMTP id <2004082715543601200p13uge>; Fri, 27 Aug 2004 15:54:36 +0000 Date: Fri, 27 Aug 2004 09:54:35 -0600 Subject: Re: Feeds MUST have alternate links? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <14be96d304082706186c6b8a00@mail.gmail.com> Message-Id: <64D331F6-F841-11D8-B9F1-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RFsfmV038397 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Friday, August 27, 2004, at 07:18 AM, Mark Pilgrim wrote: > On Fri, 27 Aug 2004 08:48:20 +0200, Asbjørn Ulsberg > wrote: >> On Thu, 26 Aug 2004 06:37:40 -0400, Sam Ruby >> wrote: >>> Let me point out that the channel link element is required in every >>> version of RSS from 0.91 to 1.0 to 2.0. >> >> ....Which is exactly why I (and others I know of) can't use RSS for >> many of >> the purposes I'd like, but instead hope to be able to use Atom in >> those >> areas. > > If you're looking for a syndication format that's even looser and has > even fewer required elements than RSS, you're in the wrong place. > While I'm all for requirements that prevent problems, I'm still wondering what problems or difficulties will arise if some entries don't have links. Anyone? From owner-atom-syntax@mail.imc.org Fri Aug 27 12:31:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14194 for ; Fri, 27 Aug 2004 12:31:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGOJoM041017; Fri, 27 Aug 2004 09:24:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RGOJnR041016; Fri, 27 Aug 2004 09:24:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGOHIe041004 for ; Fri, 27 Aug 2004 09:24:18 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 8DCE57C1F9; Fri, 27 Aug 2004 19:14:30 +0200 (CEST) To: "Mark Pilgrim" Cc: Atom-Syntax Subject: Re: Feeds MUST have alternate links? References: <87smabifw7.fsf@nwalsh.com> <412DBD74.9040904@intertwingly.net> <14be96d304082706186c6b8a00@mail.gmail.com> Message-ID: Date: Fri, 27 Aug 2004 18:25:51 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <14be96d304082706186c6b8a00@mail.gmail.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 09:18:13 -0400, Mark Pilgrim wrote: > If you're looking for a syndication format that's even looser and has > even fewer required elements than RSS, you're in the wrong place. No, that's not what I'm looking for. I just can't get the point in requiring an alternative representation for all Atom documents. I'll repeat Antone's question: «I'm still wondering what problems or difficulties will arise if some entries don't have links». -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 12:32:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14276 for ; Fri, 27 Aug 2004 12:32:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGPoek041068; Fri, 27 Aug 2004 09:25:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RGPoEQ041067; Fri, 27 Aug 2004 09:25:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGPnLc041061 for ; Fri, 27 Aug 2004 09:25:49 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id D42B47C22E; Fri, 27 Aug 2004 19:16:19 +0200 (CEST) To: "Julian Reschke" Cc: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <412F25BF.8030408@gmx.de> Message-ID: Date: Fri, 27 Aug 2004 18:27:41 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412F25BF.8030408@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 14:14:55 +0200, Julian Reschke wrote: > If he wanted that, he made a mistake. It's better if this mistake has > the same consequences in all aggregators, I would think. It _would_ have the same consequence in all conforming aggregators, since the specification should say that atom:id should be char-by-char-compared. There is still no good reason not to require or recommend publishers to canonicalize their URI's. > Atom IDs *are* simple to compare if we stick with char-by-char > comparison. I am not against char-by-char comparison. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 12:33:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14297 for ; Fri, 27 Aug 2004 12:33:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGPtG8041078; Fri, 27 Aug 2004 09:25:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RGPtKF041077; Fri, 27 Aug 2004 09:25:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGPtQO041071 for ; Fri, 27 Aug 2004 09:25:55 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7RGPnvw029321; Fri, 27 Aug 2004 12:25:51 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOV09547 (AUTH bob@wyman.us); Fri, 27 Aug 2004 12:25:48 -0400 (EDT) Message-Id: <200408271625.BOV09547@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" , "'Joe Hildebrand'" Cc: , Subject: RE: Transporting Atom Notifications over the XMLPP Date: Fri, 27 Aug 2004 12:23:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSMTOrsv7ke+u8YSCOaVtPw6lkW3AAAeyHQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <412F55FE.1080508@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > I don't yet understand the intended mapping between a feed document > and a Jabber node. The easiest way to think about this is as though a JEP-0060 "node id" is the same as the URI for an Atom feed-file. They are both simply identifiers of a "feed" of entries that will arrive over time. The only real difference is that with JEP-0060 PubSub, feed metadata isn't passed over the node itself -- it is retrieved separately using a "metadata retrieval operation" i.e. an XMPP IQ message. The atom file "http://pubsub.com/foo.xml" could be map directly to: The JEP-0060 node: "/pubsub/topics/foo" In this case, if you simply logged the entries received over the "/pubsub/topics/foo" node into a sequential file, you would have precisely the same result as if you had read the foo.xml file, except that the entries in the log file wouldn't be wrapped by an atom:feed element. (Note: We exploit this behavior at PubSub.com. We create Atom files (with atom:feed elements) that store a history of entries that are sent to the XMPP feeds. On start-up, clients first read the Atom files once and then receive further updates via the JEP-0060 PubSub protocol. It is very convenient to ensure that the syntax between the historical record and the dynamic data is the same. Also, this means that non-XMPP aggregators can read the "history" files with no problem. It works wonderfully...) > If each feed is intended to be a separate [JEP-0060] node, then I > don't see the problem with atom:id being the feed ItemId. In this case, as long as the feed file-feed in question is not an aggregate feed, then only one of the two problems I outlined in my mail would exist. We don't have to worry about the intentional or accidental reuse of atom:ids. The remaining problem relates to layering: In the presence of caching queues in the channel, or any non-instantaneous delivery of messages, some "old" messages may be discarded by the channel. Thus, clients who desired to see all messages would not be able to do so. Given the IBM Stock Price alerting application in my example, this means that you could always get "current price" of IBM's stock, but you would lose some messages that would permit "time and volume" analysis or tracking of trends over time since some messages would be silently dropped by the channel. Given that there are two conflicting styles of feed use, we can't or shouldn't "require" an item identification scheme that makes one of the styles impossible to implement. Thus, pubsub id and atom:id should be considered orthogonal. > If a given node can represent multiple feeds, then there is a clear > problem that is easy to spell out: the situation where a given entry > is syndicated in multiple feeds processed by a single node. Atom would > require the atom:id to be the same in each case, Jabber would require > the ItemId to differ. This is correct. bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 27 12:37:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14517 for ; Fri, 27 Aug 2004 12:37:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGTX6T041312; Fri, 27 Aug 2004 09:29:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RGTXRb041311; Fri, 27 Aug 2004 09:29:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RGTVI9041300 for ; Fri, 27 Aug 2004 09:29:32 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 24827 invoked by uid 65534); 27 Aug 2004 16:29:29 -0000 Received: from p508244C6.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.68.198) by mail.gmx.net (mp003) with SMTP; 27 Aug 2004 18:29:29 +0200 X-Authenticated: #1915285 Message-ID: <412F6167.6050801@gmx.de> Date: Fri, 27 Aug 2004 18:29:27 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: PaceIdConstruct References: <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4125ADB3.2060400@annevankesteren.nl> <412CF547.5020704@gmx.de> <412F25BF.8030408@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Fri, 27 Aug 2004 14:14:55 +0200, Julian Reschke > wrote: > >> If he wanted that, he made a mistake. It's better if this mistake has >> the same consequences in all aggregators, I would think. > > > It _would_ have the same consequence in all conforming aggregators, > since the specification should say that atom:id should be > char-by-char-compared. There is still no good reason not to require or > recommend publishers to canonicalize their URI's. There's no reason to require a specific behaviour when it doesn't make any difference whatsoever whether people actually do it or not. This is about spec simplicity. >> Atom IDs *are* simple to compare if we stick with char-by-char >> comparison. > > > I am not against char-by-char comparison. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Aug 27 12:42:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14987 for ; Fri, 27 Aug 2004 12:42:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGYpCG042138; Fri, 27 Aug 2004 09:34:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RGYpeZ042137; Fri, 27 Aug 2004 09:34:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGYoZ5042126 for ; Fri, 27 Aug 2004 09:34:51 -0700 (PDT) (envelope-from hildjj@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so419778rnk for ; Fri, 27 Aug 2004 09:34:50 -0700 (PDT) Received: by 10.38.15.69 with SMTP id 69mr2515333rno; Fri, 27 Aug 2004 09:34:50 -0700 (PDT) Received: by 10.38.15.47 with HTTP; Fri, 27 Aug 2004 09:34:50 -0700 (PDT) Message-ID: <82777bea040827093463240940@mail.gmail.com> Date: Fri, 27 Aug 2004 10:34:50 -0600 From: Joe Hildebrand Reply-To: Joe Hildebrand To: Sam Ruby Subject: Re: Transporting Atom Notifications over the XMLPP Cc: bob@wyman.us, atom-syntax@imc.org In-Reply-To: <412F55FE.1080508@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408270205.BOS94144@ms8.netsolmail.com> <412F4898.1070403@intertwingly.net> <82777bea040827081643427fa3@mail.gmail.com> <412F55FE.1080508@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 27 Aug 2004 11:40:46 -0400, Sam Ruby wrote: > Joe Hildebrand wrote: > > > Just to clarify, you're talking about leaving the -00 draft alone? > > No, I think the spec as currently written is dangerously ambiguous. > > If I am reading this correctly, the current consensus is that these two > concepts are orthogonal. Just to be clear: this is a clear reversal of > "No need for yet another GUID-y thing in the world."... which was an > honest and understandable opinion; the danger is that too many people > will initially form a similar opinion, and some may act upon it. Yes, this is a complete reversal of "No need for yet another GUID-y thing in the world." I was wrong. Probably not for the first time. :) > > I'd be ok with adding a suggestion for how to generate pub/sub id's > > that was non-normative. > > > > BTW, I don't care what the separator character is. Since this ID > > isn't a URI, it could even use a space as a separator. Maybe that > > would be the best bet. > > I'd recommend against issuing a specific syntax recommendation. People > would be too tempted to try to parse the id. What if the syntax recommendation was: SHA1((feed URL || (subscription jid & subscription node)) & atom:id) Where & is concatenation. No way to parse *that*. (hopefully) > I don't yet understand the intended mapping between a feed document and > a Jabber node. If each feed is intended to be a separate node, then I > don't see the problem with atom:id being the feed ItemId. I see at least 2 cases: - One node per feed ("normal" case) - Node contains items from multiple feeds ("synthetic" case) Imagine a world in which your blog tool does the xmpp publish at the same time that it wrote things to your web site. A synthetic agent could be subscribed to several normal feeds, and republish items it received. Another synthetic agent could be subscribed to that aggregate feed, etc. That can lead to the case with the same item being in the same node twice, via a diamond-shaped subscription chain: N1 N2 / \ / S1 S2 \ / S3 In N1, you don't care too much what the pub/sub id's are, since they can only come from a single place. If someone publishes again with the same id, the intent is to overwrite the old item. You would like the publisher to be able to calculate the pub/sub ID easily, so they wouldn't have to store one more GUIDy thing. In S2, you'd like to maintain the property that if an original publisher wants to overwrite an entry in N1, it would overwrite the item in the synthetic feed. You don't want items from N2 to overwrite items from N1 in S2, since there's no easy way to do end-to-end authorization. Using the ID algorithm above, S2 could ensure that IDs from N1 and N2 are always different, but that N1 could overwrite items it had originated. Since items from N1 can come from both S1 and S2 into S3, however, with different pub/sub IDs, the receiver still has to check atom:id's for uniqueness, if they want to ensure that the same item doesn't appear twice. > If a given node can represent multiple feeds, then there is a clear > problem that is easy to spell out: the situation where a given entry is > syndicated in multiple feeds processed by a single node. Atom would > require the atom:id to be the same in each case, Jabber would require > the ItemId to differ. Yes. > As a fan of informative text, examples, and even the occasional > judicious use of repetition, I would suggest an informative note which > spells out the scenario above. Would a less informal rendering of the scenario above be enough? > > On Fri, 27 Aug 2004 10:43:36 -0400, Sam Ruby wrote: > > > >>Bob Wyman wrote: > >> > >>> So, please, understand that atom:id is application specific data and > >>>should not be confused with XMPP or JEP-0060 channel specific data. The > >>>layering here is important to maintain. > >> > >>I am quite content with leaving this as: the spec as currently written > >>needs to provide some guidance here; otherwise interoperability will > >>suffer as the consequences of the available choices are not obvious. > >> > >>- Sam Ruby > -- Joe Hildebrand From owner-atom-syntax@mail.imc.org Fri Aug 27 12:45:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15215 for ; Fri, 27 Aug 2004 12:45:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGZXq2042169; Fri, 27 Aug 2004 09:35:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RGZXoE042168; Fri, 27 Aug 2004 09:35:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGZXE9042162 for ; Fri, 27 Aug 2004 09:35:33 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7RGZVvu003183; Fri, 27 Aug 2004 12:35:33 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOV13131 (AUTH bob@wyman.us); Fri, 27 Aug 2004 12:35:27 -0400 (EDT) Message-Id: <200408271635.BOV13131@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Ian Davis'" , Cc: Subject: RE: ID - wrong solution to the problem? Date: Fri, 27 Aug 2004 12:33:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSMKV+tm1/v2e+OTRKg5DG1uLaGBQAKQdwQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <412F1B83.5000809@internetalchemy.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis, on noticing that PubSub's feeds contain information says: > Why are you contesting this when your own feeds already include the > necessary structure? Yes, PubSub.com Atom feeds contain elements which, when combined with atom:id, can be used to resolve the various atom:id issues. However, ps:source-feed is a non-standard extension and has not been received well by the list. (But, I think folk will eventually realize why it is necessary...) When I discuss issues on this list, I try to stick to what is documented in the drafts and various proposals that have been made. My hope is we'll end up with an Atom specification that we can use *without* extensions to fix bugs in the spec. Thus, when people say "atom:id is ok". I am going to object -- atom:id is *NOT* sufficient, as defined, to do what is needed. > Combine this with a feed-unique ID and you may have a usable duplicate > detection mechanism. Yes. But it isn't Atom. It is "Atom + PubSub extensions". That is not good. bob wyman -----Original Message----- From: Ian Davis [mailto:iand@internetalchemy.org] Sent: Friday, August 27, 2004 7:31 AM To: bob@wyman.us Cc: atom-syntax@imc.org Subject: Re: ID - wrong solution to the problem? On 27/08/2004 02:31, Bob Wyman wrote: >>Enumerating the list of aggregated feeds is a publisher problem. ... >>There are a lot more clients than publishers. > > PubSub.com aggregates over three million feeds. If we were to > include the list of three million (and growing) in every feed we generate, > this "publisher problem" would turn into a "client problem" very quickly. Why are you contesting this when your own feeds already include the necessary structure. From http://atom.pubsub.com/c3/cd/7a625435c020f57b2536e64cc6.xml OmniWeb 5.1 Wishlist &#38; RSS News Reading Matt Henderson's Blog Combine this with a feed-unique ID and you may have a usable duplicate detection mechanism. Ian From owner-atom-syntax@mail.imc.org Fri Aug 27 13:13:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16761 for ; Fri, 27 Aug 2004 13:13:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RH2Amu044291; Fri, 27 Aug 2004 10:02:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RH2AIr044290; Fri, 27 Aug 2004 10:02:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RH298n044281 for ; Fri, 27 Aug 2004 10:02:09 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7RH26uq022253 for ; Fri, 27 Aug 2004 13:02:12 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOV23057 (AUTH bob@wyman.us); Fri, 27 Aug 2004 13:01:54 -0400 (EDT) Message-Id: <200408271701.BOV23057@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: Subject: Gush news aggregator supports Atom over XMPP Date: Fri, 27 Aug 2004 12:59:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSMV0i/9O3F5Yd2TSyIrXlM15nJPA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Gush, the integrated news aggregator and instant messaging client, now supports Atom over XMPP. Gush runs on Windows, OS X, and Linux. See: http://2entwine.com/ http://2entwine.com/archives/000246.html They say in http://2entwine.com/archives/000246.html ======================= August 27, 2004 Gush 1.2 Preview Release The Gush 1.2 Preview Release is now available. Gush's support for the PubSub service is very exciting especially for news junkies eager to find information lying around in RSS/Atom feeds. With support for PubSub built into Gush, search queries can be constructed and news items will come pouring in near-real time as PubSub discovers new items in RSS/Atom land. Read our tutorial about getting started with PubSub inside of Gush. The 1.2 release is essentially the 1.1 release with support for PubSub.com's news service. Work on the features as outlined in the road map for 1.2 have been put on hold for the past two weeks while we added PubSub support. All of the features in the road map will now be in the 1.3 release. Posted by Dudley at August 27, 2004 04:06 AM ========================== Note: This "preview" release of Gush relies on the Atom over XMPP protocol that we support at PubSub.com. It is documented at: http://pubsub.com/developers . bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 27 13:14:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16872 for ; Fri, 27 Aug 2004 13:14:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RH5l9Q044465; Fri, 27 Aug 2004 10:05:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RH5lIV044464; Fri, 27 Aug 2004 10:05:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RH5krR044458 for ; Fri, 27 Aug 2004 10:05:46 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] ([66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7RH5nwU019244; Fri, 27 Aug 2004 13:05:49 -0400 Message-ID: <412F69E1.1020907@intertwingly.net> Date: Fri, 27 Aug 2004 13:05:37 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: bob@wyman.us, atom-syntax@imc.org Subject: Re: Transporting Atom Notifications over the XMLPP References: <200408270205.BOS94144@ms8.netsolmail.com> <412F4898.1070403@intertwingly.net> <82777bea040827081643427fa3@mail.gmail.com> <412F55FE.1080508@intertwingly.net> <82777bea040827093463240940@mail.gmail.com> In-Reply-To: <82777bea040827093463240940@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > What if the syntax recommendation was: > > SHA1((feed URL || (subscription jid & subscription node)) & atom:id) > > Where & is concatenation. No way to parse *that*. (hopefully) I guess that works. It could even be an example instead of a recommendation. > I see at least 2 cases: > - One node per feed ("normal" case) > - Node contains items from multiple feeds ("synthetic" case) > [snip] > > Would a less informal rendering of the scenario above be enough? Yes. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Aug 27 13:32:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18103 for ; Fri, 27 Aug 2004 13:32:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHLW3Y045533; Fri, 27 Aug 2004 10:21:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RHLWkZ045532; Fri, 27 Aug 2004 10:21:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from dns02.mail.yahoo.co.jp (dns02.mail.yahoo.co.jp [211.14.15.205]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RHLUZW045501 for ; Fri, 27 Aug 2004 10:21:31 -0700 (PDT) (envelope-from torumyax@yahoo.co.jp) Received: from unknown (HELO yahoo.co.jp) (43.244.9.69 with poptime) by dns02.mail.yahoo.co.jp with SMTP; 27 Aug 2004 17:21:13 -0000 X-Apparently-From: Date: Sat, 28 Aug 2004 02:53:14 +0900 From: Toru Marumoto Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 3.06 In-Reply-To: References: Message-Id: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Asbjorn Ulsberg wrote: > >On Fri, 27 Aug 2004 09:18:13 -0400, Mark Pilgrim wrote: > >> If you're looking for a syndication format that's even looser and has >> even fewer required elements than RSS, you're in the wrong place. > >No, that's not what I'm looking for. I just can't get the point in >requiring an alternative representation for all Atom documents. I'll >repeat Antone's question: I'm still wondering what problems or >difficulties will arise if some entries don't have links. > imho, the whole point of syndication format is to let subscriber know that a new content is up online... not to deliver itself. Well, OK. Atom can be a content delivery format as well... But, downside is that some simple aggregators (tickers or desktop sidebars) do not show . You are supporsed to click on the title to see the acutural content on the web in a web browser. I know at least 5 of that kind of aggregators. But also,if atom entries do not require alternative representations, atom might open up new posibilities.. I don't know. Toru Marumoto see you on the web! __________________________________________________ GANBARE! NIPPON! Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE http://mail.ganbare-nippon.yahoo.co.jp/ From owner-atom-syntax@mail.imc.org Fri Aug 27 13:37:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18343 for ; Fri, 27 Aug 2004 13:37:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHRlEs045814; Fri, 27 Aug 2004 10:27:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RHRluc045813; Fri, 27 Aug 2004 10:27:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHRkfr045807 for ; Fri, 27 Aug 2004 10:27:46 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 32491 invoked by uid 17064); 27 Aug 2004 17:27:50 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.131.97]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 27 Aug 2004 17:27:50 -0000 In-Reply-To: <200408271635.BOV13131@ms8.netsolmail.com> References: <200408271635.BOV13131@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <684A93FB-F84E-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: " " From: Henry Story Subject: Re: ID - wrong solution to the problem? Date: Fri, 27 Aug 2004 19:27:44 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Aug 2004, at 18:33, Bob Wyman wrote: > > Ian Davis, on noticing that PubSub's feeds contain > information says: >> Why are you contesting this when your own feeds already include the >> necessary structure? > Yes, PubSub.com Atom feeds contain elements which, > when combined with atom:id, can be used to resolve the various atom:id > issues. why is it important to know the source feed in order for the atom:id to work correctly? Henry > [snip] > On 27/08/2004 02:31, Bob Wyman wrote: > >>> Enumerating the list of aggregated feeds is a publisher problem. ... >>> There are a lot more clients than publishers. >> >> PubSub.com aggregates over three million feeds. If we were to >> include the list of three million (and growing) in every feed we >> generate, >> this "publisher problem" would turn into a "client problem" very >> quickly. > Why are you contesting this when your own feeds already include the > necessary structure. From > http://atom.pubsub.com/c3/cd/7a625435c020f57b2536e64cc6.xml > > > OmniWeb 5.1 Wishlist &#38; RSS News Reading > > Matt Henderson's Blog > href="http://matt.makalumedia.com/"/> > href="http://matt.makalumedia.com/index.rdf"/> > > > Combine this with a feed-unique ID and you may have a usable duplicate > detection mechanism. > > Ian > From owner-atom-syntax@mail.imc.org Fri Aug 27 13:49:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19145 for ; Fri, 27 Aug 2004 13:49:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHbeZN046621; Fri, 27 Aug 2004 10:37:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RHbe0k046620; Fri, 27 Aug 2004 10:37:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHbdZb046612 for ; Fri, 27 Aug 2004 10:37:39 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 0E5017C1EE; Fri, 27 Aug 2004 20:28:10 +0200 (CEST) Date: Fri, 27 Aug 2004 19:39:48 +0200 To: "Andreas Sewe" Subject: Re: Using DC only for informational dates Cc: Atom-Syntax References: <20040812213201.52881.qmail@web41213.mail.yahoo.com> <1092397529.411ca9d96959e@webmail.djpowell.net> <1021337343.20040815024400@djpowell.net> <4124F6E7.8050209@rbg.informatik.tu-darmstadt.de> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4124F6E7.8050209@rbg.informatik.tu-darmstadt.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 19 Aug 2004 20:52:23 +0200, Andreas Sewe wrote: > That's a distinction (between protocol and metadata) well worth to make. I agree. > Now in my opinion the dates from dcterms are all informational metadata > about the publishing process that produced a given entry. None of these > dates are essential for the protocol - perhaps with the sole exception > of dcterms:modified. They aren't essential to the format itself either, but they are indeed useful for a lot of purposes (and people). Since people are so resilient to have the Dublin Core dates in the format (specification), maybe we should put them in the protocol (specification) instead? Some examples of how Dublin Core dates could be used in the protocol: - A future 'available' date could make the protocol implementation hide the entry until the assigned point in time arrives. - When someone creates an entry with POST, 'issued', 'created' and 'modified' are set. ('created' could of course be set on the client in offline scenarios and such.) - When someone updates an existing entry with PUT, 'modified' is set. > That's because the date of the last modification is useful for the user > agent itself - even if the user is never interested in it. Similarly the > date of the last major modification might be useful for the user agent, > too, to keep its local cache of entries up-to-date. So I consider both > atom:modified and atom:updated to be dates that are useful as part of > the protocol. 'available' is certainly also useful, both for the server and client implementation. 'issued' and 'created' are useful in historical and archival scenarios. > Now one might argue whether a (protocol) atom:modified is indeed the > same as a (metadata) dcterms:modified, or if the latter only refers to a > modification in terms of the given publishing process whereas the former > reflects all modification including the "low-level" ones like e.g. > changing the case of an xml:lang attribute's content. That's a meta-meta discussion. If people are less resilient to have the Dublin Core dates as a part of Atom (whatever namespace they may reside in) if they belong to the protocol and not to the format, I think it's a path worth exploring. So far, everyone have thought it should be a part of the format, but since most of the DC dates are format publishing-specific dates, don't they fit better in the protocol specification? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 13:49:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19231 for ; Fri, 27 Aug 2004 13:49:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHemdQ046782; Fri, 27 Aug 2004 10:40:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RHemrA046781; Fri, 27 Aug 2004 10:40:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHelIU046766 for ; Fri, 27 Aug 2004 10:40:47 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 491767C1EE; Fri, 27 Aug 2004 20:31:18 +0200 (CEST) Date: Fri, 27 Aug 2004 19:42:57 +0200 To: "Martin Duerst" Subject: Re: PaceIdConstruct Cc: Atom-Syntax References: <4124EEE2.6000703@annevankesteren.nl> <20040819142837.34119.qmail@web41205.mail.yahoo.com> <4124C3FC.80000@intertwingly.net> <4124EEE2.6000703@annevankesteren.nl> <4.2.0.58.J.20040822173548.05025ed0@localhost> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4.2.0.58.J.20040822173548.05025ed0@localhost> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sun, 22 Aug 2004 17:37:05 +0900, Martin Duerst wrote: > Just a small point: There is no requirement to store IRIs as UTF-8. Of course. My point wasn't that they were stored as UTF-8, but that most DNS servers and such currently have problems with UTF-8 URI's. But since atom:id is not dereferencable, what DNS's supports isn't very interesting. Which is why IRI's are easier to deploy in atom:id than in other, dereferencable URI's. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 14:03:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19964 for ; Fri, 27 Aug 2004 14:03:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHrltr047425; Fri, 27 Aug 2004 10:53:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RHrlxg047424; Fri, 27 Aug 2004 10:53:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHrg0k047417 for ; Fri, 27 Aug 2004 10:53:43 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7RHrkil022357 for ; Fri, 27 Aug 2004 11:53:46 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3400HKR9PMAO@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 27 Aug 2004 11:53:46 -0600 (MDT) Received: from [192.168.1.2] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I3400CTN9PLE1@mail.sun.net> for atom-syntax@imc.org; Fri, 27 Aug 2004 11:53:45 -0600 (MDT) Date: Fri, 27 Aug 2004 10:53:30 -0700 From: Tim Bray Subject: Work Queue Rotation #7 To: Atom WG Cc: Joe Gregorio , Robert Sayre , Mark Nottingham Message-id: <01BB2B94-F852-11D8-BAB9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Co-chairs' take on consensus on the current discussion items. As always, the floor is open for push-back. PaceDigitalSignatures I think we have consensus to accept this, with a hard restriction that we use child-only signatures, and slight variation in language to say that you can't ignore a message because it has a signature (http://imc.org/atom-syntax/mail-archive/msg08804.html) Sayre said (http://imc.org/atom-syntax/mail-archive/msg08817.html) that we need a standard way of linking to external signatures, but nobody picked up on this idea. Rob, I think you're going to have to do some more work if you really want that. Examples on this one would be helpful; Mark Pilgrim had provided some but they were envelope signatures. PaceErrVerb PaceServiceError The only discussion was from Sayre (http://imc.org/atom-syntax/mail-archive/msg08841.html) lightly changing PaceServiceError. I don't think this has consensus to go forward. I guess they go back in Revisit for one more look, but if someone wants to say "close them" they won't get any resistance from the co-chairs. PaceEquivalents This does not have anything like consensus backing. Our feeling is that it's unlikely to get consensus in another try, so would suggest closing it. Ayers proposes a note saying the Atom terms are specializations of the DC terms: http://imc.org/atom-syntax/mail-archive/msg08863.html Hmm, if he wants to do a private I-D? PaceItemLicense Two -1's, no support. Close it. PaceReduceMustMay No support. Everyone agrees that we should use 2119 language appropriately and correctly. There is little support for saying anything else. Close it. PaceSimplifiedFeedFormat No support, a coherent call for closure from Graham. Close it. -Tim From owner-atom-syntax@mail.imc.org Fri Aug 27 14:04:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20028 for ; Fri, 27 Aug 2004 14:04:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHumXS047599; Fri, 27 Aug 2004 10:56:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RHumVD047598; Fri, 27 Aug 2004 10:56:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHul30047586 for ; Fri, 27 Aug 2004 10:56:47 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2E1277C1EE; Fri, 27 Aug 2004 20:47:18 +0200 (CEST) Date: Fri, 27 Aug 2004 19:59:01 +0200 To: "Toru Marumoto" Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax References: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 02:53:14 +0900, Toru Marumoto wrote: > imho, the whole point of syndication format is to let subscriber know > that a new content is up online... not to deliver itself. That was the point of RSS, yes. I think and hope Atom will give a bit more than RSS to users and implementors. > Well, OK. Atom can be a content delivery format as well... Indeed. > But, downside is that some simple aggregators (tickers or desktop > sidebars) do not show . You are supporsed to click on the title > to see the acutural content on the web in a web browser. If they break without , can't they just don't show entries without one, then: [Untested PHP5 pseudo code] foreach ($feed->entry as $entry) { if (isset($entry->link[0])) { // Display the entry } } [Untested XSLT pseudo code] [Untested C# pseudo code] foreach (XmlElement entry in feed.ChildNodes) { if (entry.SelectSingleNode("//atom:link") != null) { // Display the entry } } This check is really simple. I really can't understand the big problem about optional links. I do see problems with required links, though. > But also,if atom entries do not require alternative representations, > atom might open up new posibilities.. Exactly. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 14:08:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20295 for ; Fri, 27 Aug 2004 14:08:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHvlkV047639; Fri, 27 Aug 2004 10:57:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RHvlvo047638; Fri, 27 Aug 2004 10:57:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RHvkXF047632 for ; Fri, 27 Aug 2004 10:57:46 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@ms8.netsolmail.com [216.168.230.180] (may be forged)) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7RHvh6i002793; Fri, 27 Aug 2004 13:57:47 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOV43129 (AUTH bob@wyman.us); Fri, 27 Aug 2004 13:57:42 -0400 (EDT) Message-Id: <200408271757.BOV43129@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Henry Story'" , "'Atom Syntax'" Cc: Subject: A method for verifying cross-feed atom:id uses Date: Fri, 27 Aug 2004 13:55:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSMWzhw1Qpk/xghTqyDWKbcw+7TCgAAOwUA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <684A93FB-F84E-11D8-ADE0-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > why is it important to know the source feed in order for the atom:id > to work correctly? A service like PubSub.com's, can use "source-feed" as a means to verify that some uses of identical atom:id's in multiple feeds are legitimate. Method 1: When an item is received that contains a source-feed indicator that is not the same as the feed for which the item was read, the aggregator can treat this as a "ping"[0] and rather than using the new entry directly, it can scan or re-scan the indicated source-feed to extract the original copy of the entry. As long as the entry is still in the source-feed, things will work well. If the entry is not in the source-feed, local policy would be used to decide if the entry should be discarded or given a new atom:id. A similar, although less reliable, method can be used in the absence of source-feed data. Method 2: In this method, the aggregator would record all seen atom:ids along with the source-feeds in which they were discovered. Then, if another instance of an atom:id is found, the service would determine if the current instance came from the same feed as the previous instance. If so, then the new entry would be treated as a replacement for the old one. If not, the service would re-fetch the feed in which the atom:id was previously found and attempt to recover the original entry. If the original can be recovered, it would be used. If not, then local policy would determine if the more recent entry should be deleted, passed on as legitimate, or rewritten with a new atom:id. (This method relies on the assumption that the "authoritative" entry will always be read *before* any "spoof" or "malicious" entries are read. This may not be a good assumption.) Both of these methods require a good bit of work by the aggregator. While it is completely reasonable for a service like PubSub's to do this stuff, it might be considered onerous for desktop clients due to the increased latency in reporting new entries to users as well as the increased processing requirements and network traffic loads. Nonetheless, the methods above would allow a service like PubSub's to have greater confidence that the correct data was being distributed. There remains an issue related to "attribution". Even if the original source of an entry is retrieved, the aggregator probably must remember the feed in which the entry's existence was discovered. The problem is that you might have someone who is interested in "all entries from blog 'A'". In this case, even if the original source of an entry was Blog 'B', you should still deliver a copy to the subscriber. We have no syntax at present to allow the specification of "delivery via" or "alternate feeds" (different from rel="alternate") in Atom. Thus, maintaining this data would require private extensions to Atom. bob wyman [0] "Pinging" is the process by which blog CMS software informs aggregators that the blog has been updated. See: http://blo.gs , http://pingomatic.com/ etc. From owner-atom-syntax@mail.imc.org Fri Aug 27 14:12:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20618 for ; Fri, 27 Aug 2004 14:12:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RI4r8U047964; Fri, 27 Aug 2004 11:04:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RI4rpk047963; Fri, 27 Aug 2004 11:04:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RI4qi8047956 for ; Fri, 27 Aug 2004 11:04:53 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc12) with SMTP id <2004082718045101200p8k8ue>; Fri, 27 Aug 2004 18:04:51 +0000 Date: Fri, 27 Aug 2004 12:04:50 -0600 Subject: Re: Feeds MUST have alternate links? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <96B8B252-F853-11D8-B9F1-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, August 27, 2004, at 11:53 AM, Toru Marumoto wrote: >> I'm still wondering what problems or >> difficulties will arise if some entries don't have links. > imho, the whole point of syndication format is to let subscriber know > that a new content is up online... not to deliver itself. > Well, OK. Atom can be a content delivery format as well... I've heard enough people complain about feeds that have only summaries rather than full content to think that Atom has a life as a content delivery format. > But, downside is that some simple aggregators (tickers or desktop > sidebars) do not show . You are supporsed to click on the > title to see the acutural content on the web in a web browser. I know > at least 5 of that kind of aggregators. Okay, that could be an issue. A few thoughts on mitigating problems: 1) If the end user is subscribing to the feed where the entries originate, they can unsubscribe to feeds that don't include links in their entries. 2) If a service is aggregating feeds to serve to people using such an application (the software vendor also serves content), they can omit such feeds. 3) The application itself (or the aggregation service) could omit any items that don't have links (or could at least have an option to--it's possible that people might be interested in reading the headlines even if they can't get directly to a bigger story--like the news ticker at the bottom of the TV screen on CNN). From owner-atom-syntax@mail.imc.org Fri Aug 27 14:31:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21966 for ; Fri, 27 Aug 2004 14:31:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIK546048862; Fri, 27 Aug 2004 11:20:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIK5KA048861; Fri, 27 Aug 2004 11:20:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RIK4Qn048846 for ; Fri, 27 Aug 2004 11:20:05 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 59969 messnum 1915038 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 27 Aug 2004 18:20:02 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail02.svc.cra.dublin.eircom.net (qp 59969) with SMTP; 27 Aug 2004 18:20:02 -0000 Message-ID: <412F7B4C.2070407@dehora.net> Date: Fri, 27 Aug 2004 19:19:56 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom WG Subject: Re: Work Queue Rotation #7 References: <01BB2B94-F852-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <01BB2B94-F852-11D8-BAB9-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > Sayre said (http://imc.org/atom-syntax/mail-archive/msg08817.html) that > we need a standard way of linking to external signatures, but nobody > picked up on this idea. Rob, I think you're going to have to do some > more work if you really want that. Datapoint: http://www.ws-i.org/Profiles/AttachmentsProfile-1.0-2004-08-24.html#Referencing_Attachments_from_the_SOAP_Envelope SonOfSwA lives. cheers Bill From owner-atom-syntax@mail.imc.org Fri Aug 27 14:43:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23213 for ; Fri, 27 Aug 2004 14:43:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIWioR049814; Fri, 27 Aug 2004 11:32:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIWilD049813; Fri, 27 Aug 2004 11:32:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIWhQG049807 for ; Fri, 27 Aug 2004 11:32:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7RIWl2G026833 for ; Fri, 27 Aug 2004 11:32:47 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i7RIWjd2019515 for ; Fri, 27 Aug 2004 11:32:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200408271757.BOV43129@ms8.netsolmail.com> References: <200408271757.BOV43129@ms8.netsolmail.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--639751979; protocol="application/pkcs7-signature" Message-Id: <7CF32AB3-F857-11D8-8440-000A95DC3D90@mac.com> From: Graham Subject: Re: A method for verifying cross-feed atom:id uses Date: Fri, 27 Aug 2004 11:32:43 -0700 To: "'Atom Syntax'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-7--639751979 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit For God sake people, it's time to stop feeding the troll. We're having IDs that are globally unique URIs. There's no need to justify it to anyone again. Graham --Apple-Mail-7--639751979 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI3MTgzMjQ0WjAjBgkqhkiG9w0BCQQxFgQUKr+5t6LP9VSg7jwjBbpFXvxN 1AwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAzYt79mA6GYNc9HUK2ZQCClYw JZcns9Flr0Xaxc3sGmeweiAL0dGqc1vd+Qn/1jaaBHvrCecjXaBiiLkN04ooi+cVHl0XPyKAJPgf Q7/R+E2hhkNKyEOGABdM4eQT6J0sBsi0cXE/D4qr0uv+pATbQjjtiRN/LapT358iXjCUhVhsRMfW JPxfK90gdkBg5szEFH2dpeEBAsnTXvbf6Tt3/KYuwYVVHe6OHoW3lEMQtq5oJTv395zLaAUhdhST HKSxBeKC8wEvGXp5dhC6W9V2D9KmQsGo3H/YbstOHNs55HPzIQb/75GKFiGkvWtFb3MoSEkB0uf1 ud2Di0pjUA5FuQAAAAAAAA== --Apple-Mail-7--639751979-- From owner-atom-syntax@mail.imc.org Fri Aug 27 14:43:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23231 for ; Fri, 27 Aug 2004 14:43:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIZMgv050161; Fri, 27 Aug 2004 11:35:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIZMpX050160; Fri, 27 Aug 2004 11:35:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIZL7i050154 for ; Fri, 27 Aug 2004 11:35:21 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7RIZPJd006027 for ; Fri, 27 Aug 2004 11:35:25 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i7RIZNd2020263 for ; Fri, 27 Aug 2004 11:35:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <412F42D1.5060103@cwru.edu> References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--639591617; protocol="application/pkcs7-signature" Message-Id: From: Graham Subject: Re: URIs vs Strings Date: Fri, 27 Aug 2004 11:35:24 -0700 To: "'Atom Syntax'" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-9--639591617 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Jeremy, Asjborn, Grayrest, you can't +1 things without explaining what they achieve. Graham --Apple-Mail-9--639591617 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI3MTgzNTI1WjAjBgkqhkiG9w0BCQQxFgQUe85Aaz+uy+yU+RBNDTbIOhqv A/wweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAiTyBAc/RQ9556NS+WPcKbD0H 3WS8WkaVYOlEjY9aOYVK8+UbacDpR/eCMCv9cEnowaL5AlqRvAYiGVbrGuYtH/SBIgfB+ChunbIr ssa71j1IzeDJcn7y6Rl2H7FrH/DMflyR8S05fq5qxC6MZMmBiTijWkMqJM9ciCAJ6C/t6Ah2rYyp eUQNN9+Tgukd6WpC0aHxzk2szIBTaLRYdVHOklaoIulW5uM+d5/hmqssy2bjtT3h6b89JUs4gOrM ZLInplAaWZRLC3lTwi53qHZWVoaHNYagjQySxRW2+JjPtsMPfPkezNYeaDePjvrI57KM3SEckE+r RS2YCl7WkNa3zwAAAAAAAA== --Apple-Mail-9--639591617-- From owner-atom-syntax@mail.imc.org Fri Aug 27 14:52:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24446 for ; Fri, 27 Aug 2004 14:52:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIfDoA050604; Fri, 27 Aug 2004 11:41:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIfDDe050603; Fri, 27 Aug 2004 11:41:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIfCLj050597 for ; Fri, 27 Aug 2004 11:41:12 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7RIfLBf023248; Fri, 27 Aug 2004 14:41:21 -0400 Message-ID: <412F804A.6000405@intertwingly.net> Date: Fri, 27 Aug 2004 14:41:14 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: Feeds MUST have alternate links? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > >> But also,if atom entries do not require alternative representations, >> atom might open up new posibilities.. > > Exactly. Before anybody spends much time on creating a Pace, just be aware that this particular secretary will be very reluctant to schedule discussions around topics that are out of scope until or unless the charter is revised to include the topic in question. The reason for this is quite simple: we are having a hard enough time staying on track for things that are in scope without dealing with explorations of new possible applications. I direct everybody interested in pursuing this to read the first sentence of the charter and try to come up with meaningful examples of web resources for which Universal Resource Identifiers can not be provided. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Aug 27 14:55:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24699 for ; Fri, 27 Aug 2004 14:55:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIlQe6051037; Fri, 27 Aug 2004 11:47:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIlQdk051036; Fri, 27 Aug 2004 11:47:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIlPM1051029 for ; Fri, 27 Aug 2004 11:47:25 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@ms8.netsolmail.com [216.168.230.180] (may be forged)) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7RIlP6g022065; Fri, 27 Aug 2004 14:47:27 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOV60242 (AUTH bob@wyman.us); Fri, 27 Aug 2004 14:47:22 -0400 (EDT) Message-Id: <200408271847.BOV60242@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Dare Obasanjo'" , "'Sam Ruby'" , "'AsbjXrn_Ulsberg'" Cc: "'Norman Walsh'" , "'Atom-Syntax'" Subject: RE: Feeds MUST have alternate links? Date: Fri, 27 Aug 2004 14:45:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSLgJJPGaCCw7qrSv2OyYVdwnpLqgA5CPPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040826145735.79336.qmail@web41206.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > I'm in the process of adding NNTP support to RSS Bandit. > Would 'news:microsoft.public.dotnet.xml' be an > acceptable value? Our NNTP support at PubSub.com needs a good bit of work... However, below you'll find a sample of what we're currently doing. I would be very happy to work with folk on defining the "proper" representation of an NNTP item in an Atom feed. (what do we do with all the extra headers? What do we do with "To", "From", etc?) <![CDATA[ Re: C#.NET vs VB.NET ]]> <![CDATA[ hr.comp.programiranje.dotnet ]]> 2004-08-10T05:01:43-04:00 2004-08-10T05:01:43-04:00 ... bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 27 15:00:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25075 for ; Fri, 27 Aug 2004 15:00:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIp6eE051287; Fri, 27 Aug 2004 11:51:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RIp6se051286; Fri, 27 Aug 2004 11:51:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RIp50J051279 for ; Fri, 27 Aug 2004 11:51:05 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0loW-0007vp-R4; Fri, 27 Aug 2004 18:51:05 +0000 Message-ID: <412F829B.7080903@franklinmint.fm> Date: Fri, 27 Aug 2004 14:51:07 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom WG , Joe Gregorio , Mark Nottingham Subject: Re: Work Queue Rotation #7 References: <01BB2B94-F852-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <01BB2B94-F852-11D8-BAB9-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > Co-chairs' take on consensus on the current discussion items. As > always, the floor is open for push-back. > > PaceDigitalSignatures > > I think we have consensus to accept this, with a hard restriction that > we use child-only signatures, and slight variation in language to say > that you can't ignore a message because it has a signature > (http://imc.org/atom-syntax/mail-archive/msg08804.html) > > Sayre said (http://imc.org/atom-syntax/mail-archive/msg08817.html) that > we need a standard way of linking to external signatures, but nobody > picked up on this idea. Rob, I think you're going to have to do some > more work if you really want that. > I don't feel strongly about it. I was only repeating Mark P. and Paul. > > PaceErrVerb > PaceServiceError > > The only discussion was from Sayre > (http://imc.org/atom-syntax/mail-archive/msg08841.html) lightly changing > PaceServiceError. I don't think this has consensus to go forward. I > guess they go back in Revisit for one more look, but if someone wants to > say "close them" they won't get any resistance from the co-chairs. > I called for PaceErrVerb to be closed (http://www.imc.org/atom-syntax/mail-archive/msg08959.html). In the past, when PaceServiceError was actually debated, there were a number of people who favored it. I'm puzzled that the chairs consider lack of discussion to be an accurate indicator of consensus against it, especially when objections of others have repeatedly considered and usually *incorporated* into the proposal. The remaining criticisms seem to come from people opposed to "extending HTTP", yet those same people have no problem with atom-specific headers. More likely, PaceServiceError wasn't discussed because the list has been full of repetitive, redundant posts about IDs, Dates, and RDF. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Aug 27 15:15:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26707 for ; Fri, 27 Aug 2004 15:15:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJ2s7l052031; Fri, 27 Aug 2004 12:02:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJ2s3X052030; Fri, 27 Aug 2004 12:02:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mirapoint2.tis.cwru.edu (IDENT:mirapoint@mirapoint2.TIS.CWRU.Edu [129.22.104.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJ2rTX052021 for ; Fri, 27 Aug 2004 12:02:53 -0700 (PDT) (envelope-from jms18@cwru.edu) Received: from [129.22.114.48] (magonia.ITS.CWRU.Edu [129.22.114.48]) by mirapoint2.tis.cwru.edu (MOS 3.4.3-CR) with ESMTP id BYX07419 (AUTH jms18); Fri, 27 Aug 2004 15:02:33 -0400 (EDT) Message-ID: <412F8557.3030305@cwru.edu> Date: Fri, 27 Aug 2004 15:02:47 -0400 From: Jeremy Smith User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom Syntax'" Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080002000004070000070601" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms080002000004070000070601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Jeremy, Asjborn, Grayrest, you can't +1 things without explaining what > they achieve. > > Graham I believe that others have summed up the benefits of canonicalization at length. I can add my own unique perspective, I suppose. Either producers are going to have to canonicalize URIs or consumers will have to before performing comparisons. I think that the appropriate place in which to "sink that complexity" is in the producers of atom feeds. If it is not done at the producer level, then such logic will become distributed across all of the different atom-parsing libraries that get released into the wild. I believe it is much more appropriate to centralize the canonicalization logic within the producers of atom feeds. That, and, it just seems "right" to canonicalize URIs; but that could just be me. Jeremy --------------ms080002000004070000070601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII3TCC AskwggIyoAMCAQICAwuUFzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMTI3MTczNjAyWhcNMDUwMTI2MTczNjAy WjBAMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR0wGwYJKoZIhvcNAQkBFg5q bXMxOEBjd3J1LmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPf8o5eHqNJc 9J/QGkeJl8ZkhHrSE7B2aNu3uZ58dVbu4fCrZS19yqbkBku1dwCvu6rmdk77yJDDyo8XW6k2 IUOgVNtUcwd+OPv7xy2vt0KhM/X8UioVo7uKH4Al85tl82Q5+u/8sF5meFUB7WqrdkxdvTry 3Dy72D3kU0HOaRF1ZxgYzx0+EhBxTn7NovNM5ssS82sS+nGIkxildehWM77SbpwBa2/aVUUu G/M7LUF9aA1JIZ2mVaEpCD/CFXj94bkqDEBTprMN53qFcuCvzf1wjaYKYI1gRHygeBDEgiLQ Vdt8S6ah80gwfRdU67ureZCPauNhPh5Z8bioB+oGw7sCAwEAAaMrMCkwGQYDVR0RBBIwEIEO am1zMThAY3dydS5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC9ORgJ8o22 9pge8784ly/Rkt2twNDH2YSi7VtDBykSqehza6efNUilYF1G6AbyK285QkkjyR5hiz8RGdrW WC3Qx+OyJpptqK6rVVsFRjpQA+6U5+ZZj2Bo3AxusdfTr3rDqoulruA7auxsst7agq4gOlCw y3srzsNw0Zekvu/aVDCCAskwggIyoAMCAQICAwuUFzANBgkqhkiG9w0BAQQFADBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMTI3MTczNjAy WhcNMDUwMTI2MTczNjAyWjBAMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR0w GwYJKoZIhvcNAQkBFg5qbXMxOEBjd3J1LmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAPf8o5eHqNJc9J/QGkeJl8ZkhHrSE7B2aNu3uZ58dVbu4fCrZS19yqbkBku1dwCv u6rmdk77yJDDyo8XW6k2IUOgVNtUcwd+OPv7xy2vt0KhM/X8UioVo7uKH4Al85tl82Q5+u/8 sF5meFUB7WqrdkxdvTry3Dy72D3kU0HOaRF1ZxgYzx0+EhBxTn7NovNM5ssS82sS+nGIkxil dehWM77SbpwBa2/aVUUuG/M7LUF9aA1JIZ2mVaEpCD/CFXj94bkqDEBTprMN53qFcuCvzf1w jaYKYI1gRHygeBDEgiLQVdt8S6ah80gwfRdU67ureZCPauNhPh5Z8bioB+oGw7sCAwEAAaMr MCkwGQYDVR0RBBIwEIEOam1zMThAY3dydS5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQC9ORgJ8o229pge8784ly/Rkt2twNDH2YSi7VtDBykSqehza6efNUilYF1G6Aby K285QkkjyR5hiz8RGdrWWC3Qx+OyJpptqK6rVVsFRjpQA+6U5+ZZj2Bo3AxusdfTr3rDqoul ruA7auxsst7agq4gOlCwy3srzsNw0Zekvu/aVDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC5QXMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA0MDgyNzE5MDI0N1owIwYJKoZIhvcNAQkEMRYEFLDnh98erPaZQxt/ Lx3EMyfaicgxMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFr MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLlBcw egYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDC5QXMA0GCSqGSIb3DQEBAQUABIIBACHFk/7p06Q1aEZRlDRHnr4bByBO LeopySI7744ptFQyx8TlZmq4MKwUmxZ0SAl85i0UuRVxJfNxGLUFDRaXbeHeJ1lgoZSl5Dia SX72rmGAOwWre3LnarbC3MFr/uUAwGGigVP15HUXy9jBTG4CVbL7TAgFAhACD9tl0rmfJ1gx IOeQoEgd8wrh2cZtvpyXNMbOTyUXkTSA2+rept/OKXENJJcHiPaGHwbxgeQ9qXkmGo4livGN c856/y3WPMh1hN9tlPxFRUVWCfbhqzKpV5+2qXNg5hlMujEmc0Rdh+FYK30+9OL6Yu+SoZWh b2TnYBvdF63si38XOTr5nTHG/cIAAAAAAAA= --------------ms080002000004070000070601-- From owner-atom-syntax@mail.imc.org Fri Aug 27 15:19:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27177 for ; Fri, 27 Aug 2004 15:19:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJ7O25052298; Fri, 27 Aug 2004 12:07:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJ7ORY052297; Fri, 27 Aug 2004 12:07:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJ7O7j052291 for ; Fri, 27 Aug 2004 12:07:24 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7RJ7Sao000418 for ; Fri, 27 Aug 2004 12:07:28 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i7RJ7MM0007013 for ; Fri, 27 Aug 2004 12:07:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) To: "'Atom Syntax'" Message-Id: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--637675028; protocol="application/pkcs7-signature" From: Graham Subject: PaceIdConstruct2 created Date: Fri, 27 Aug 2004 12:07:20 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-10--637675028 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit (btw Can I use localhost or file: in my id?) == Abstract == Replacement for PaceIdContruct based on [http://www.imc.org/atom-syntax/mail-archive/msg08572.html this message] from the mailing list. == Status == Open == Related paces == * ["PaceIdContruct"] * ["PaceCanonicalIds"] * ["PaceComparingIds"] * ["PaceRecommendIdScheme"] == Rationale == Replace clunky language in PaceIdConstruct == Proposal == Replace section 4.2.6 and 5.5, append a section to "3. Common Atom Constructs", and modify section 5.12: === 3.5 Identification Constructs === Identification Constructs convey an identifier that is used to associate different instances of the same resource. Whenever a resource appears in an Atom Document, its identifier SHOULD be the same as any other times it has appeared in an Atom Document, and MUST NOT be the same as the identifier currently or formerly used for any other Atom resource. Changes to the content or location of the resource MUST NOT change the identifier. All Atom Documents published by the same entity MUST use the same identifier for each respective resource they publish. The content of an Identification Construct MUST be an absolute URI (see RFC 2396), which MAY come from any scheme. When the URI comes from a resolvable scheme, it MAY resolve to any resource, and MAY not resolve successfully. Implementations therefore MUST NOT assume there is any particular relationship between the resource the identifier belongs to and any resource it resolves to. Two identifiers are considered to be the same when their content is composed of the same characters. Two identifiers whose that are composed of different characters but contain URIs that are themselves equivalent in a looser sense MUST NOT be considered the same. All comparisons MUST be case sensitive. A system that accepts input in Atom format that it subsequently outputs in Atom format SHOULD pass through the values of all identifiers. (append canonicalization and examples if you so wish) === 4.2.6 "atom:id" Element === "atom:id" is an Identification construct that identifies instances of the same feed. atom:head elements MUST contain an atom:id element, but MUST NOT contain more than one. Two feeds may be considered instances of one another when the atom:id element inside their respective atom:head elements contain the same identifier, but implementations MUST NOT assume they contain the same content. === 5.5 "atom:id" Element === "atom:id" is an Identification construct that identifies instances of the same entry. atom:entry elements MUST contain an atom:id element, but MUST NOT contain more than one. Two entries may be considered instances of one another when their atom:id elements contain same identifier, but implementations MUST NOT assume they contain the same content. === 5.12 "atom:origin" Element === The "atom:origin" element's content conveys the original source of the entry; e.g., the feed where the entry was first published. If the source is an Atom Feed Document, then the content of atom:origin MUST be the identifier in that document's atom:head section. (And if not?) The content of this element MUST be a URI. atom:entry elements MAY contain an atom:origin element, but MUST NOT contain more than one. --Apple-Mail-10--637675028 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI3MTkwNzIxWjAjBgkqhkiG9w0BCQQxFgQUtMsHuZx4Xj3aYsr4R6FMAXMY H7MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEADwYQglPT6j8oyVzCpSGn7q+C H6MsPiS0rTN4SsUCi6RiUaMxxzKViSjxHNwApj6A4paCgzyUTi5RFXqnH0c0ukWkxjbMr8FKvcIA K4VlsN3LSqqiEcoLhJ0DD3ylkSw5pnFuTcQfq0HUqbFizCEdJRx+SQft8nGUEnhMp6e6vTPbPEID 10fHkBEOJlqYMzZJy3BpHf7FpLAmF5ecDYmoU001FDEhuOF/dKW1jZAn2EYNWqOAVZokvFH7R75P dBx0CnwQGNecYm5oWRM//TkUcl+eLV6sKXPgnfnjHZYp2gEIEXOGjAgMc6x2wiWPNGR0YmXemc94 sBsoSUxSOBZi1QAAAAAAAA== --Apple-Mail-10--637675028-- From owner-atom-syntax@mail.imc.org Fri Aug 27 15:26:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28188 for ; Fri, 27 Aug 2004 15:26:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJGUJ7052958; Fri, 27 Aug 2004 12:16:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJGUtN052957; Fri, 27 Aug 2004 12:16:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJGU5a052950 for ; Fri, 27 Aug 2004 12:16:30 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7RJG3SW020013; Fri, 27 Aug 2004 12:16:03 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i7RJG2Cv001264; Fri, 27 Aug 2004 12:16:03 -0700 (PDT) In-Reply-To: <476b71e8040827121130f61e1b@mail.gmail.com> References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <476b71e8040827121130f61e1b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--637152988; protocol="application/pkcs7-signature" Message-Id: <8A11B42C-F85D-11D8-8440-000A95DC3D90@mac.com> Cc: "'Atom Syntax'" From: Graham Subject: Re: URIs vs Strings Date: Fri, 27 Aug 2004 12:16:03 -0700 To: grayrest X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-11--637152988 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 27 Aug 2004, at 12:11 pm, grayrest wrote: > I can imagine someone misinterpreting/forgetting that this is the > case. C14ning the URI for > publishers means that even if an implementor doesn't realize that IDs > are not URIs, simple changes like changing ports doesn't cause ids to > shift. Erm, changing ports changes the canonical value too. Sorry - try again. Graham --Apple-Mail-11--637152988 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI3MTkxNjAzWjAjBgkqhkiG9w0BCQQxFgQU6qJ/NN90xlI0be0FvZHWr5su OQYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAvw5yVo3XSY4iC04WXrAI5Dpf veMrWD5eiXbfTd71yj/BVmXbHz0xYlJ0BdrZeI1iHhYGegEugdAhzspHhGnfWkrapJYlvSUFJef7 NTRMreeAOaZUpOqq3SGwy//OHeyMWtxsLvuA1fCypw9P44DESpTE5gWUsq+EQR9DlU+blch5jMIA btM8bha7QJ0NSH1Q7hMgmLzIMbUkrUWe6ysm/ynyib4BBockriohTeObiUPWGXU0V7NhnrXDwWhi xbwVueUy4k+M2jZHUKZF9zaJDTpTLb5CDbIqm5WySqwk6XpVwBWNkLsqAdkKzHMCDH4J4ixXBSMX fV5rMwpdq31uLQAAAAAAAA== --Apple-Mail-11--637152988-- From owner-atom-syntax@mail.imc.org Fri Aug 27 15:26:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28275 for ; Fri, 27 Aug 2004 15:26:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJHdSr053053; Fri, 27 Aug 2004 12:17:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJHdkH053052; Fri, 27 Aug 2004 12:17:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJHdUw053046 for ; Fri, 27 Aug 2004 12:17:39 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7RJHgAm001223; Fri, 27 Aug 2004 12:17:42 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i7RJHZd2002692; Fri, 27 Aug 2004 12:17:39 -0700 (PDT) In-Reply-To: <412F8557.3030305@cwru.edu> References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <412F8557.3030305@cwru.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12--637059219; protocol="application/pkcs7-signature" Message-Id: Cc: "'Atom Syntax'" From: Graham Subject: Re: URIs vs Strings Date: Fri, 27 Aug 2004 12:17:36 -0700 To: Jeremy Smith X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-12--637059219 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 27 Aug 2004, at 12:02 pm, Jeremy Smith wrote: > Either producers are going to have to canonicalize URIs or > consumers will have to before performing comparisons. Sorry, no one has to and the system works just as well. Try again. Graham --Apple-Mail-12--637059219 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI3MTkxNzM3WjAjBgkqhkiG9w0BCQQxFgQUPsgwLSo4U8PVsPW6E8GvpCrr NagweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAONWiqyoZYLjEfPrJ9sGo2wcY sW/oQpT4re5L/YXElqHm7rqvYFncmG4DdDIcfctsYuSE5aUZ3fA7TI2pvZ510K77N8QW5RRFeCQS BxTB9zdnXcAEd80Y8Gv7FX6AqFHXi2eqDlHK8VUrULptniaaSG0uKbaEmkOATd044BNcAsjt5/9f AkPZtddHPU5wbfEcY4qxngpUMSQjClpBqzkfVvpydlhOTaxOrpxsCl9HqwlPdNtp5/r9+MHMWfKV PKigjpyFHLmFfTRN7hqn/wOmT5f5iybVOewE+urqGc2w3+B9bGVASKmrAJc44v76tr4BiIjPC7Y6 9WcJYPDe5ZqYzQAAAAAAAA== --Apple-Mail-12--637059219-- From owner-atom-syntax@mail.imc.org Fri Aug 27 15:29:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28522 for ; Fri, 27 Aug 2004 15:29:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJGhSh052980; Fri, 27 Aug 2004 12:16:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJGhTg052979; Fri, 27 Aug 2004 12:16:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJGgNp052965 for ; Fri, 27 Aug 2004 12:16:43 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 61DEA7C1EE; Fri, 27 Aug 2004 22:07:13 +0200 (CEST) Date: Fri, 27 Aug 2004 21:19:12 +0200 To: "Sam Ruby" Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax References: <412F804A.6000405@intertwingly.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <412F804A.6000405@intertwingly.net> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 14:41:14 -0400, Sam Ruby wrote: > Before anybody spends much time on creating a Pace, just be aware that > this particular secretary will be very reluctant to schedule discussions > around topics that are out of scope until or unless the charter is > revised to include the topic in question. That's understood. > I direct everybody interested in pursuing this to read the first > sentence of the charter and try to come up with meaningful examples of > web resources for which Universal Resource Identifiers can not be > provided. The problem isn't providing URI's, but that they are supposed to be _alternate_ representations of the feed or entries. Is the URI of the feed you're looking at a good «alternate» URI for the feed? I think not, since it's not alternate, but instead some notion of «me» or «this». For Atom entries, the situation is a bit different, since in many cases it would be useful to only use Atom feeds as transport loads and not have the entries represent anything else but themselves. That is, the entries inside a feed are first-class resources with no alternate representations. Of course, all entries might be pulled out and placed on each own's URI location, but that creates the same «alternate» problem as with feeds. If the resource you refer to from the entry is infact the exact same resource you're looking at, the referred resource isn't an alternate representation. It's _the_ representation. If the specification only required an atom:link element without specifying the values of @type or @rel, it would be better, but I still think atom:link should be optional alltogether, at least for atom:entry. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 15:41:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29151 for ; Fri, 27 Aug 2004 15:41:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJVCMc054487; Fri, 27 Aug 2004 12:31:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJVCoS054486; Fri, 27 Aug 2004 12:31:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJVCRP054469 for ; Fri, 27 Aug 2004 12:31:12 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7RJVBuq019953 for ; Fri, 27 Aug 2004 15:31:15 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOV74238 (AUTH bob@wyman.us); Fri, 27 Aug 2004 15:31:10 -0400 (EDT) Message-Id: <200408271931.BOV74238@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom syntax'" Subject: RE: URIs vs Strings Date: Fri, 27 Aug 2004 15:29:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSLMXB7ZSvta1QoSbuZOiWqfRP4tABOkRhQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <1093499193.3389.13.camel@homer> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > Google for "DEC AND UUID" or "Microsoft AND GUID". For those who didn't find the Digital source code for generating UUIDs, (Not everyone remembers that DEC was Digital... see: http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-le ach-uuids-guids-00.txt The code is copyright 1989 by HP and DEC... If my memory serves me correctly, we actually started using the UUID code, or a predecessor, at DEC at least five years earlier. bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 27 15:52:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00271 for ; Fri, 27 Aug 2004 15:52:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJiIld055653; Fri, 27 Aug 2004 12:44:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJiIRO055652; Fri, 27 Aug 2004 12:44:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJiHZv055633 for ; Fri, 27 Aug 2004 12:44:17 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 878767C1EE; Fri, 27 Aug 2004 22:34:47 +0200 (CEST) To: "Janne Jalkanen" Cc: Atom-Syntax Subject: Re: Link requirements [was : Can atom be Del.icio.us?] References: <81395121-F6CA-11D8-AFC5-003065EA6144@geckotribe.com> <412F3B15.2070009@nokia.com> Message-ID: Date: Fri, 27 Aug 2004 21:46:55 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <412F3B15.2070009@nokia.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 16:45:57 +0300, Janne Jalkanen wrote: > I just think a syndication format should be able to stand on its own, > without any references to external resources, that's all. It would make > Atom more attractive to machine-to-machine communication. I agree. Many (if not most) of my Atom usages will be machine-to-machine, not machine-to-human. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 15:55:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00608 for ; Fri, 27 Aug 2004 15:55:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJkdLU055787; Fri, 27 Aug 2004 12:46:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RJkdux055786; Fri, 27 Aug 2004 12:46:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RJkcJg055772 for ; Fri, 27 Aug 2004 12:46:38 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id EB7327C1EE; Fri, 27 Aug 2004 22:37:08 +0200 (CEST) Date: Fri, 27 Aug 2004 21:49:16 +0200 To: mint@franklinmint.fm Subject: Re: Link requirements Cc: Atom-Syntax References: <81395121-F6CA-11D8-AFC5-003065EA6144@geckotribe.com> <412F3B15.2070009@nokia.com> <412F562B.5080601@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <412F562B.5080601@franklinmint.fm> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 11:41:31 -0400, Robert Sayre wrote: > Take a look at PaceLinkDelicious. Currently, it requires "alternate". I > could see requiring either "about" or "alternate", but not omitting both. Requiring «about» for feeds makes sense, or at least isn't very problematic. For entries, though, I think it's a problem. What's the use of having every atom:entry both inside the feed and on its own URI somewhere, when both are identical? E.g., the atom:entry inside the feed is the full representation that doesn't have a higher class alternative. > After all, we're defining a format for syndication of Web resources[0]. Can't the atom:entry's inside atom:feed be syndicated directly? Do they need alternative representations (or «about» URI's) to be syndicable? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 16:20:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04350 for ; Fri, 27 Aug 2004 16:20:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RK9VEI057133; Fri, 27 Aug 2004 13:09:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RK9Vjv057132; Fri, 27 Aug 2004 13:09:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RK9UK1057126 for ; Fri, 27 Aug 2004 13:09:30 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7RK9Yil029068 for ; Fri, 27 Aug 2004 14:09:34 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3400HDCFZYAO@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 27 Aug 2004 14:09:34 -0600 (MDT) Received: from [192.168.1.2] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I34003PLFZXL5@mail.sun.net> for atom-syntax@imc.org; Fri, 27 Aug 2004 14:09:34 -0600 (MDT) Date: Fri, 27 Aug 2004 13:09:29 -0700 From: Tim Bray Subject: Re: Work Queue Rotation #7 In-reply-to: <412F829B.7080903@franklinmint.fm> To: Atom WG Message-id: <00E91885-F865-11D8-BAB9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <01BB2B94-F852-11D8-BAB9-000A95A51C9E@sun.com> <412F829B.7080903@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 27, 2004, at 11:51 AM, Robert Sayre wrote: >> PaceErrVerb >> PaceServiceError >> The only discussion was from Sayre >> (http://imc.org/atom-syntax/mail-archive/msg08841.html) lightly >> changing PaceServiceError. I don't think this has consensus to go >> forward. I guess they go back in Revisit for one more look, but if >> someone wants to say "close them" they won't get any resistance from >> the co-chairs. > > I called for PaceErrVerb to be closed > (http://www.imc.org/atom-syntax/mail-archive/msg08959.html). > > In the past, when PaceServiceError was actually debated, there were a > number of people who favored it. > > I'm puzzled that the chairs consider lack of discussion... The co-chairs freely admit that they have to do a certain amount of guessing and inferring, and that errors are inevitable. Sometimes we've read silence one way, sometimes another. Better luck to these two next time around. > More likely, PaceServiceError wasn't discussed because the list has > been full of repetitive, redundant posts about IDs, Dates, and RDF. You have a point. -Tim From owner-atom-syntax@mail.imc.org Fri Aug 27 16:22:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04661 for ; Fri, 27 Aug 2004 16:22:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKDT4W057325; Fri, 27 Aug 2004 13:13:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RKDT72057324; Fri, 27 Aug 2004 13:13:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKDSxq057302 for ; Fri, 27 Aug 2004 13:13:29 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 64F867C1EE; Fri, 27 Aug 2004 23:03:59 +0200 (CEST) Date: Fri, 27 Aug 2004 22:16:13 +0200 To: mint@franklinmint.fm Subject: Re: Close PaceErrVerb References: <412E1CA2.9030404@franklinmint.fm> Cc: Atom-Syntax From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <412E1CA2.9030404@franklinmint.fm> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2004 13:23:46 -0400, Robert Sayre wrote: > Now that PaceServiceError uses its own HTTP method, the only substantive > differences are: > > * payload > * whether error requests must be sent to the requestURI I still think PaceErrVerb is more RESTful in the way that the erronous resource is the one that is being ERRed upon, but the ErrorURI might of course be the same URI as the resource. I think PaceErrVerb is simpler. No ErrorURI, just a method. ERR the erronous resource, and you're done. Add an explanatory request body if you want to say something more in your ERR. > PaceServiceError could easily be adjusted to accommodate either of these > requirements, and is more thoroughly specified in almost every area they > have in common. That's something I can agree with. PaceServiceError is much better specified, but a bit more complicated to implement. If we could try to implement some of PaceErrVerb's simpleness into PaceServiceError, I would be very happy. I'm also not sure if I like the GRUMBLE method. ;-) > Unless someone steps forward offering to complete PaceErrVerb, we should > close it. I'm not against closing it if we agree on doing some changes in PaceServiceError. Those changes could probably be discussed off-list, unless everyone is interested in the discussion(?). -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 16:36:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07884 for ; Fri, 27 Aug 2004 16:36:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKQJFk058748; Fri, 27 Aug 2004 13:26:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RKQJqv058747; Fri, 27 Aug 2004 13:26:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKQIVZ058735 for ; Fri, 27 Aug 2004 13:26:19 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 0BC227C1EE; Fri, 27 Aug 2004 23:16:49 +0200 (CEST) Date: Fri, 27 Aug 2004 22:29:06 +0200 To: "Tim Bray" Subject: Re: Work Queue Rotation #7 Cc: Atom-Syntax References: <01BB2B94-F852-11D8-BAB9-000A95A51C9E@sun.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <01BB2B94-F852-11D8-BAB9-000A95A51C9E@sun.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 10:53:30 -0700, Tim Bray wrote: > Sayre said (http://imc.org/atom-syntax/mail-archive/msg08817.html) that > we need a standard way of linking to external signatures, but nobody > picked up on this idea. Rob, I think you're going to have to do some > more work if you really want that. I like the idea, but as Robert, I don't feel very strongly about it. Nice to have, but not at all a must-have. > PaceErrVerb > PaceServiceError These two will probably conflate over the next days, which will result in closure of PaceErrVerb. > PaceEquivalents > > This does not have anything like consensus backing. That's my feeling too, although the text in this pace is useful, to some degree. Maybe it can be put in an informative appendix? > PaceSimplifiedFeedFormat > > No support, a coherent call for closure from Graham. Close it. I think this has been re-written so many times and currently is so off with the rest of the specification that it needs to be closed and restarted to get the text and proposal right. It tries to define both simple Atom feeds that only contain pointers to resources as well as Atom entries as stand-alone documents. These two proposals would be better served if they were in two different paces, imho. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 16:56:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10172 for ; Fri, 27 Aug 2004 16:56:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKlr5N060248; Fri, 27 Aug 2004 13:47:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RKlrgH060247; Fri, 27 Aug 2004 13:47:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RKlq9f060234 for ; Fri, 27 Aug 2004 13:47:52 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id E20407C1EE; Fri, 27 Aug 2004 23:38:22 +0200 (CEST) Date: Fri, 27 Aug 2004 22:50:45 +0200 To: Graham Subject: Re: PaceIdConstruct2 created Cc: Atom-Syntax References: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 12:07:20 -0700, Graham wrote: > (btw Can I use localhost or file: in my id?) No to localhost, yes to file. Imho, that is. > Identification Constructs convey an identifier that is used to > associate different instances of the same resource. This sentence is a bit fuzzy. I understand what you mean (by reading on), but it isn't very clear. > Two identifiers are considered to be the same when their content is > composed of the same characters. Two identifiers whose that are > composed of different characters but contain URIs that are themselves > equivalent in a looser sense MUST NOT be considered the same. All > comparisons MUST be case sensitive. This paragraph was very difficult to read. I'm not really sure how to implement what you write there. > A system that accepts input in Atom format that it subsequently outputs > in Atom format SHOULD pass through the values of all identifiers. «..that it subsequently..» should be «..which it subsequently..», no? And why only SHOULD and not MUST? Is it okay for synthetic feeds to create new ID's for Atom entries? > === 4.2.6 "atom:id" Element === > > "atom:id" is an Identification construct that identifies instances of > the same feed. Does it identify instances, really? Won't that give a new ID for each instance of the feed? > atom:head elements MUST contain an atom:id element, but MUST NOT > contain more than one. Two feeds may be considered instances > of one another when the atom:id element inside their respective > atom:head elements contain the same identifier, but implementations > MUST NOT assume they contain the same content. Also a bit fuzzy wording in this paragraph. I don't know how to improve it (yet), unfortunately. > "atom:id" is an Identification construct that identifies instances of > the same entry. atom:entry elements MUST contain an atom:id element, > but MUST NOT contain more than one. Two entries may be considered > instances of one another when their atom:id elements contain same > identifier, but implementations MUST NOT assume they contain the same > content. The same here as above. > === 5.12 "atom:origin" Element === > > The "atom:origin" element's content conveys the original source of the > entry; e.g., the feed where the entry was first published. > > If the source is an Atom Feed Document, then the content of atom:origin > MUST be the identifier in that document's atom:head section. «..then the content of atom:origin MUST be the Identification Construct of that feed» is clearer, imho. > (And if not?) What else than a feed may an Atom entry originate from? > The content of this element MUST be a URI. atom:entry elements MAY > contain an atom:origin element, but MUST NOT contain more than one. How many atom:origin elements may an entry contain? Zero? One? Infinate? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 17:11:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11201 for ; Fri, 27 Aug 2004 17:11:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RL2Ugf061154; Fri, 27 Aug 2004 14:02:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RL2UCX061153; Fri, 27 Aug 2004 14:02:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RL2TFP061146 for ; Fri, 27 Aug 2004 14:02:30 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0nrg-0003ed-UL; Fri, 27 Aug 2004 21:02:29 +0000 Message-ID: <412FA168.40708@franklinmint.fm> Date: Fri, 27 Aug 2004 17:02:32 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: Close PaceErrVerb References: <412E1CA2.9030404@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Thu, 26 Aug 2004 13:23:46 -0400, Robert Sayre > wrote: > >> Now that PaceServiceError uses its own HTTP method, the only >> substantive differences are: >> >> * payload >> * whether error requests must be sent to the requestURI > > > I still think PaceErrVerb is more RESTful in the way that the erronous > resource is the one that is being ERRed upon, but the ErrorURI might of > course be the same URI as the resource. > ErrorURI is not required to be the same URI as the original request because this is not a realistic requirement for a large proportion of Atom deployment scenarios. Also, note that a second URI is likely more robust than sending a request to the resource that is known to be misconfigured. > >> Unless someone steps forward offering to complete PaceErrVerb, we >> should close it. > > > I'm not against closing it if we agree on doing some changes in > PaceServiceError. PaceServiceError has just recently incorporated an "ErrVerb". You can examine the numerous contributions from this list in the Notes and Discussion sections [0]. You may also wish to examine the precedents cited there: Pingback, Mozilla, and ebXML. If you're still interested, you can examine the 158 edits that the Pace has undergone[1]. I'm not saying the Pace is finished or even acceptable in principle. However, note that the only two contentious issues we've managed to be somewhat productive on (so far) are PaceSimpleResourcePosting and PaceServiceError. Robert Sayre [0] http://www.intertwingly.net/wiki/pie/PaceServiceError#head-70440046a3dc2e079f23ee1c57dfa76669b732aa [1] http://www.intertwingly.net/wiki/pie/PaceServiceError?action=info From owner-atom-syntax@mail.imc.org Fri Aug 27 17:22:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12102 for ; Fri, 27 Aug 2004 17:22:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLCM0p062103; Fri, 27 Aug 2004 14:12:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RLCMCY062102; Fri, 27 Aug 2004 14:12:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLCL41062095 for ; Fri, 27 Aug 2004 14:12:22 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <2004082721121501600jpuose>; Fri, 27 Aug 2004 21:12:20 +0000 Date: Fri, 27 Aug 2004 15:12:14 -0600 Subject: Re: URIs vs Strings Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, August 27, 2004, at 01:17 PM, Graham wrote: > On 27 Aug 2004, at 12:02 pm, Jeremy Smith wrote: >> Either producers are going to have to canonicalize URIs or consumers >> will have to before performing comparisons. > Sorry, no one has to and the system works just as well. Try again. Because IDs are to be compared character-by-character, the only reason to canonicalize is to reduce the probability of accidentally generating the same ID differently at different times (right?). In case Graham's response didn't get the point across, consumers don't need to canonicalize, because they compare IDs character-by-character--the burden of ensuring that an entry's ID is character-by-character the same as it ever was is entirely on the producer. After all the discussion on this topic, I could do without canonicalization as long as we make the point extremely clear that clients are going to be doing character-by-character comparisons, so producers won't think they have wiggle room just because IDs look like URIs. However, unless someone can show that canonicalization would be unduly difficult in some non-edge case, I'd still require it if it were up to me because it's a good way to get the message across unequivocally that there's no wiggle room. From owner-atom-syntax@mail.imc.org Fri Aug 27 18:44:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17497 for ; Fri, 27 Aug 2004 18:44:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RMYjRH067840; Fri, 27 Aug 2004 15:34:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RMYjhE067839; Fri, 27 Aug 2004 15:34:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RMYiTw067827 for ; Fri, 27 Aug 2004 15:34:44 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 3305A7C1EE; Sat, 28 Aug 2004 01:25:10 +0200 (CEST) To: Graham Cc: Atom-Syntax Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> Message-ID: Date: Sat, 28 Aug 2004 00:36:50 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 11:35:24 -0700, Graham wrote: > Jeremy, Asjborn, Grayrest, you can't +1 things without explaining what > they achieve. Antone just explained it pretty clearly, so I don't see any need to copy+paste his reply in this thread. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Aug 27 22:53:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01030 for ; Fri, 27 Aug 2004 22:53:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S2htHm084249; Fri, 27 Aug 2004 19:43:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S2ht2M084248; Fri, 27 Aug 2004 19:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S2htoL084241 for ; Fri, 27 Aug 2004 19:43:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7S2i1SW019523; Fri, 27 Aug 2004 19:44:01 -0700 (PDT) Received: from [10.232.75.81] ([17.255.241.46]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i7S2hxCv023481; Fri, 27 Aug 2004 19:44:01 -0700 (PDT) In-Reply-To: References: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17--610272714; protocol="application/pkcs7-signature" Message-Id: <1FF6038B-F89C-11D8-8440-000A95DC3D90@mac.com> Cc: Atom-Syntax From: Graham Subject: Re: PaceIdConstruct2 created Date: Fri, 27 Aug 2004 19:44:03 -0700 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-17--610272714 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 27 Aug 2004, at 1:50 pm, Asbj=F8rn Ulsberg wrote: >> Identification Constructs convey an identifier that is used to >> associate different instances of the same resource. > > This sentence is a bit fuzzy. I understand what you mean (by reading=20= > on), but it isn't very clear. It's only meant to introduce the concept, nothing more. > This paragraph was very difficult to read. I'm not really sure how to=20= > implement what you write there. That middle sentence needs a bit of reconfiguration, I admit. But it's=20= clear enough to me. > =AB..that it subsequently..=BB should be =AB..which it = subsequently..=BB, no? I never know the correct grammar there. > And why only SHOULD and not MUST? Is it okay for synthetic feeds to=20 > create new ID's for Atom entries? MUST implies that software at the other end can rely on the same entry=20= arriving from two different sources always having the same id, and I=20 don't think it can. "system" describes much more than synthetic feeds -=20= it could have been in RSS, HTML, PDF or dead-tree format while crossing=20= the system. SHOULD is as strong as is viable. >> "atom:id" is an Identification construct that identifies instances of >> the same feed. > > Does it identify instances, really? Won't that give a new ID for each=20= > instance of the feed? I'll replace identfies with associates. >> =3D=3D=3D 5.12 "atom:origin" Element =3D=3D=3D >> >> The "atom:origin" element's content conveys the original source of = the >> entry; e.g., the feed where the entry was first published. >> >> If the source is an Atom Feed Document, then the content of=20 >> atom:origin >> MUST be the identifier in that document's atom:head section. > > =AB..then the content of atom:origin MUST be the Identification=20 > Construct of that feed=BB is clearer, imho. Yes, but we haven't defined such a thing. >> (And if not?) > > What else than a feed may an Atom entry originate from? I lifted that section from Tim's version, though I added the question.=20= I presume HTML or RSS, but it doesn't say what to put in atom:origin if=20= so. >> The content of this element MUST be a URI. atom:entry elements MAY >> contain an atom:origin element, but MUST NOT contain more than one. > > How many atom:origin elements may an entry contain? Zero? One?=20 > Infinate? Doesn't that specify exactly 0 or 1? Graham= --Apple-Mail-17--610272714 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwODI4MDI0NDA0WjAjBgkqhkiG9w0BCQQxFgQUaqusoxrMrlsBmMVu5jIp+EoB b5sweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEApu2jUt1zOLBPCdB362i9FJw8 XHZiTRFMluPdxEYp+WfRBRCgP4fSd+l3uqkkTMMWTXZZB7ARKSbAU5+pMEQj/Mz8Y9GV3xR1elNj RcXCtrt7qR2tlDJhI02z424OqbZLhFBF2UxsY8sej352CQ7/O6U0Gm2i2LvM/sFqu5iS/ca0l7/I TJQPrPU683/YDtOzz+sUJcEdlgoQUxoLx+FfJesKmqjx/SZSZdQRnsMBjLSD0wLGGsJ3pz/juENU nH0YDULCjvY8sZMbN9odRexSZDAZvB8QozS0fP3BejuqSctWlrFk5tNYf4FATuSrRHFfKOL5IBk4 zYap65AzoLwKTgAAAAAAAA== --Apple-Mail-17--610272714-- From owner-atom-syntax@mail.imc.org Sat Aug 28 01:02:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06829 for ; Sat, 28 Aug 2004 01:02:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S4k3ZU092166; Fri, 27 Aug 2004 21:46:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S4k30i092165; Fri, 27 Aug 2004 21:46:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S4k3DQ092159 for ; Fri, 27 Aug 2004 21:46:03 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C0v6O-0000uq-TY; Sat, 28 Aug 2004 04:46:09 +0000 Message-ID: <41300E12.50909@franklinmint.fm> Date: Sat, 28 Aug 2004 00:46:10 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: "'Atom Syntax'" Subject: Re: PaceIdConstruct2 created References: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> In-Reply-To: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > (btw Can I use localhost or file: in my id?) > Or private IP ranges (e.g. 192.168.1.1)... Gah! I guess so. What happens when someone puts that stuff in src? I really do need to try some webpages with my friendly neighborhood Tomcat Manager App's URIs in the src attribute. > Identification Constructs convey an identifier that is used to associate > different instances of the same resource. Whenever a resource appears in > an Atom Document, its identifier SHOULD be the same as any other times > it has appeared in an Atom Document, and MUST NOT be the same as the > identifier currently or formerly used for any other Atom resource. > Changes to the content or location of the resource MUST NOT change the > identifier. You seem to be circling the definition of URIs and Resources. You've failed to get your intent across (IMHO), but I couldn't do better. > All Atom Documents published by the same entity MUST use the > same identifier for each respective resource they publish. > > The content of an Identification Construct MUST be an absolute URI (see > RFC 2396), -1. URIs with fragments should be ok. Nitpick? Yes. > which MAY come from any scheme. This statement is redundant. > When the URI comes from a > resolvable scheme, it MAY resolve to any resource, and MAY not resolve > successfully. Implementations therefore MUST NOT assume there is any > particular relationship between the resource the identifier belongs to > and any resource it resolves to. -1. If the scheme is resolvable, there sure is a relationship, even if it is "404 Not Found", for example. We don't get to define schemes. > > Two identifiers are considered to be the same when their content is > composed of the same characters. Two identifiers whose that are composed > of different characters but contain URIs that are themselves equivalent > in a looser sense MUST NOT be considered the same. All comparisons MUST > be case sensitive. > Since the format spec defines Atom in terms of the XML Infoset, it would be best to to state that IDs are identical only when their Infoset props are identical (i.e. char-by-char). > A system that accepts input in Atom format that it subsequently outputs > in Atom format SHOULD pass through the values of all identifiers. > The intent here is good, the wording is not. Once again, I don't have an improvement to suggest. Since this Pace puts for essentially the same ideas that PaceIdConstruct does, I think mnot should take this Pace into account when drafting 02. Beyond that, I don't see that any action can be taken at this time. Diffs against the next draft could be more obviously beneficial. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 04:49:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02607 for ; Sat, 28 Aug 2004 04:49:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S8OJHU028989; Sat, 28 Aug 2004 01:24:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S8OJwA028988; Sat, 28 Aug 2004 01:24:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S8OImS028979 for ; Sat, 28 Aug 2004 01:24:18 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so46399rnb for ; Sat, 28 Aug 2004 01:24:15 -0700 (PDT) Received: by 10.38.206.45 with SMTP id d45mr543247rng; Sat, 28 Aug 2004 01:24:15 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sat, 28 Aug 2004 01:24:15 -0700 (PDT) Message-ID: <1f2ed5cd040828012461fa49d7@mail.gmail.com> Date: Sat, 28 Aug 2004 10:24:15 +0200 From: Danny Ayers Reply-To: Danny Ayers To: "Asbjørn Ulsberg" Subject: Re: URIs vs Strings Cc: Graham , Atom-Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was a little concerned about specifying string comparison-only for URIs, and unclear on how RDF URIrefs related to URIrefs in RFC 2396bis. So I queried the uri@w3.org list, and Roy Fielding was kind enough to clarify for me [1]. Bottom line is there are unlikely to be any major problems with the string-comparison approach, but in any case such problems can be avoided entirely if the IDs are canonical. I don't know of a precedent for requiring URI canonicalization, so would hesitate to mandate it. But I think the next spec draft ought at least say publishers SHOULD use canonical URIs, and based on experiences with that the decision can be made on whether a MUST would be better. This is assuming clients SHOULD use string comparison, and MUST preserve ids in a form that retains this ability (i.e. within whatever encoding is used) if republishing. Cheers, Danny. [1] http://lists.w3.org/Archives/Public/uri/2004Aug/0092.html -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Aug 28 04:56:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02941 for ; Sat, 28 Aug 2004 04:56:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S8bUdI034084; Sat, 28 Aug 2004 01:37:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S8bUuU034083; Sat, 28 Aug 2004 01:37:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7S8bTi2034039 for ; Sat, 28 Aug 2004 01:37:29 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 3838 invoked by uid 65534); 28 Aug 2004 08:37:19 -0000 Received: from dsl-213-023-058-205.arcor-ip.net (EHLO localhost) (213.23.58.205) by mail.gmx.net (mp011) with SMTP; 28 Aug 2004 10:37:19 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Graham Cc: "'Atom Syntax'" Subject: Re: PaceIdConstruct2 created Date: Sat, 28 Aug 2004 10:37:08 +0200 Message-ID: <413339e4.199654337@smtp.bjoern.hoehrmann.de> References: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> In-Reply-To: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Graham wrote: >Identification Constructs convey an identifier that is used to >associate different instances of the same resource. Whenever a resource >appears in an Atom Document, its identifier SHOULD be the same as any >other times it has appeared in an Atom Document, and MUST NOT be the >same as the identifier currently or formerly used for any other Atom >resource. I am opposed to such conformance requirements that require universal knowledge to determine conformance or such that allow anyone to make my future Atom content non-conforming. >Changes to the content or location of the resource MUST NOT >change the identifier. All Atom Documents published by the same entity >MUST use the same identifier for each respective resource they publish. I can't make sense of the last sentence here, what does it mean? >A system that accepts input in Atom format that it subsequently outputs >in Atom format SHOULD pass through the values of all identifiers. Why is this a SHOULD? What are cases where it would be acceptable or even desired to behave that way? >=== 5.5 "atom:id" Element === > >"atom:id" is an Identification construct that identifies instances of >the same entry. atom:entry elements MUST contain an atom:id element, >but MUST NOT contain more than one. Two entries may be considered >instances of one another when their atom:id elements contain same >identifier, but implementations MUST NOT assume they contain the same >content. What does it mean for an implementation to assume that two entries contain the same content? What does it mean not to do that? This clearly lacks a processing model, my understanding is that much of the date and id discussions are just about how implementations determine whether they present an entry as one the user might wish to read. There is not much point in discussing when two IDs are considered equivalent if that does not yield in clear implications for Atom implementations. Say there are two feed which are equivalent as defined by XML C14N except that the IDs in the document use a different host name, are implementations that treat the entries in the feeds as equivalent non-conforming? Say there are two feeds that are equivalent as above except that the IDs in the document use different case for the scheme component of the ID, are implementations that treat the entries in the feeds as equivalent non-conforming? Say there are two entries for which human testing determines them as very different yet they have the same ID, are implementations that treat the entries as very different as opposed to treating one entry as a modified version of the other entry non-conforming? If such implementations are non-conforming, how reasonable is it to expect that implementations will actually conform to such requirements? From owner-atom-syntax@mail.imc.org Sat Aug 28 04:59:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03103 for ; Sat, 28 Aug 2004 04:59:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S8egiw034534; Sat, 28 Aug 2004 01:40:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S8egLu034533; Sat, 28 Aug 2004 01:40:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7S8efSi034515 for ; Sat, 28 Aug 2004 01:40:42 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 6380 invoked by uid 65534); 28 Aug 2004 08:40:36 -0000 Received: from dsl-213-023-058-205.arcor-ip.net (EHLO localhost) (213.23.58.205) by mail.gmx.net (mp002) with SMTP; 28 Aug 2004 10:40:36 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: atom-syntax@imc.org Subject: Re: PaceIdConstruct2 created Date: Sat, 28 Aug 2004 10:40:25 +0200 Message-ID: <41344466.202344656@smtp.bjoern.hoehrmann.de> References: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Asbjørn Ulsberg wrote: >> (And if not?) > >What else than a feed may an Atom entry originate from? What may it not originate from? From owner-atom-syntax@mail.imc.org Sat Aug 28 05:20:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04199 for ; Sat, 28 Aug 2004 05:20:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S96Ulg038310; Sat, 28 Aug 2004 02:06:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S96U1f038308; Sat, 28 Aug 2004 02:06:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7S96TNp038275 for ; Sat, 28 Aug 2004 02:06:29 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 28982 invoked by uid 65534); 28 Aug 2004 09:06:24 -0000 Received: from dsl-213-023-058-205.arcor-ip.net (EHLO localhost) (213.23.58.205) by mail.gmx.net (mp023) with SMTP; 28 Aug 2004 11:06:24 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Mark Pilgrim Cc: atom-syntax@imc.org Subject: Re: Feeds MUST have alternate links? Date: Sat, 28 Aug 2004 11:06:12 +0200 Message-ID: <41354676.202872184@smtp.bjoern.hoehrmann.de> References: <87smabifw7.fsf@nwalsh.com> <412DBD74.9040904@intertwingly.net> <14be96d304082706186c6b8a00@mail.gmail.com> In-Reply-To: <14be96d304082706186c6b8a00@mail.gmail.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Mark Pilgrim wrote: >If you're looking for a syndication format that's even looser and has >even fewer required elements than RSS, you're in the wrong place. It is http://www.google.com/search?q=intitle%3A%22untitled+document%22 http://www.google.com/search?q=intitle%3A%22Welcome+to+Adobe+GoLive%22 http://www.google.com/search?q=intitle%3A%22Willkommen+bei+Adobe+GoLive%22 ... pointless to require presence of meta data that is not required for interoperability, and making meta data up just to satisfy obscure requirements in a specification actually reduces the value of the meta data when used properly. For the examples above it seems obvious that it would have been better to omit the element and allow implementations to determine a title from the content of the document, <h1> elements for example. From owner-atom-syntax@mail.imc.org Sat Aug 28 05:39:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05218 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 05:39:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9Ko3x040673; Sat, 28 Aug 2004 02:20:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S9KoEK040672; Sat, 28 Aug 2004 02:20:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9KnpP040566 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 02:20:50 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 668DF7C1EE; Sat, 28 Aug 2004 12:11:06 +0200 (CEST) To: "Bjoern Hoehrmann" <derhoermi@gmx.net> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: PaceIdConstruct2 created References: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> <opsder6viyuvpchu@quark> <41344466.202344656@smtp.bjoern.hoehrmann.de> Message-ID: <opsdfqz0kpuvpchu@quark> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Sat, 28 Aug 2004 11:22:38 +0200 In-Reply-To: <41344466.202344656@smtp.bjoern.hoehrmann.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 10:40:25 +0200, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: >> What else than a feed may an Atom entry originate from? > > What may it not originate from? It needs to originate from something with an identifyer, or else atom:origin makes no sense. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 05:41:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05298 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 05:41:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9MjuY041253; Sat, 28 Aug 2004 02:22:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S9MjQg041252; Sat, 28 Aug 2004 02:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9MiMO041235 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 02:22:44 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id AF8427C1EE; Sat, 28 Aug 2004 12:13:05 +0200 (CEST) To: "Danny Ayers" <danny.ayers@gmail.com> Cc: Graham <dtcd@mac.com>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> Message-ID: <opsdfq3ciyuvpchu@quark> Date: Sat, 28 Aug 2004 11:24:38 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <1f2ed5cd040828012461fa49d7@mail.gmail.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 10:24:15 +0200, Danny Ayers <danny.ayers@gmail.com> wrote: > Bottom line is there are unlikely to be any major problems with the > string-comparison approach, but in any case such problems can be > avoided entirely if the IDs are canonical. Exactly. > I don't know of a precedent for requiring URI canonicalization, so > would hesitate to mandate it. But I think the next spec draft ought at > least say publishers SHOULD use canonical URIs, and based on > experiences with that the decision can be made on whether a MUST would > be better. I think SHOULD is enough, but if we get consensus around MUST, that is great. > This is assuming clients SHOULD use string comparison, and MUST > preserve ids in a form that retains this ability (i.e. within whatever > encoding is used) if republishing. Yes to both; I think they should. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 06:06:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06169 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 06:06:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9fVIU044181; Sat, 28 Aug 2004 02:41:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S9fVn3044180; Sat, 28 Aug 2004 02:41:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9fVcI044174 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 02:41:31 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 58324 invoked by uid 17064); 28 Aug 2004 09:41:31 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.9.20]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <bob@wyman.us>; 28 Aug 2004 09:41:31 -0000 In-Reply-To: <200408271757.BOV43129@ms8.netsolmail.com> References: <200408271757.BOV43129@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D33E14C-F8D6-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "<bob@wyman.us> <bob@wyman.us>" <bob@wyman.us> From: Henry Story <henry.story@bblfish.net> Subject: Re: A method for verifying cross-feed atom:id uses Date: Sat, 28 Aug 2004 11:41:24 +0200 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 27 Aug 2004, at 19:55, Bob Wyman wrote: > > Henry Story wrote: >> why is it important to know the source feed in order for the atom:id >> to work correctly? > > A service like PubSub.com's, can use "source-feed" as a means to > verify that some uses of identical atom:id's in multiple feeds are > legitimate. I think there are many other ways to do this also. First of all notice that if someone is maliciously changing id's they could also maliciously change the source-feed. That is then up to the justice system to stop those people. We here have defined what is correct behavior on which the judicial system can work. The most protective system would be one that adds a signature for an entry that takes an entry id, a person, a version id, and signs the content proving that all of these were generated together. Perhaps something for a future version of Atom. Finally there are other methods that are based on your very good motto "It's the Entries, Stupid!" [1] I have taken that motto to heart in my latest N3 model [2]. There a feed is just a pointer to a bunch of entries <> a :Feed ; :dynamic <> ; :entry <entry.2004-08-13-1047.n3> , <entry.2004-08-13-1445.n3> , <entry.2004-08-13-1752.n3> , <entry.2004-08-13-1632.n3> ; with a little info to allow one to decide whether the entries have changed: <entry.2004-08-13-1047.n3> :entry-version <tag:bblfish.net/20040813/1047/blog1#version1> ; :id <tag:bblfish.net/20040813/1047/blog1> . Each entry is a resource (REST), where we can find all the information about the entry itself. When feeds are first fetched by agregators, the location of the entries will in the overwhelming majority of cases not have changed position. so if entry.2004-08-13-1047.n3 appears on two of my feeds, because I have a "personal" feed, and a general feed. It will be clear to the aggregator that the content can be found in the same location, and so is the same. That entry file will be the place to look for the definitive id, in case of confusion. Henry [1] http://www.imc.org/atom-syntax/mail-archive/msg04596.html [2] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html > > Method 1: When an item is received that contains a source-feed > indicator that is not the same as the feed for which the item was > read, the > aggregator can treat this as a "ping"[0] and rather than using the new > entry > directly, it can scan or re-scan the indicated source-feed to extract > the > original copy of the entry. As long as the entry is still in the > source-feed, things will work well. If the entry is not in the > source-feed, > local policy would be used to decide if the entry should be discarded > or > given a new atom:id. > > A similar, although less reliable, method can be used in the absence > of source-feed data. > > Method 2: In this method, the aggregator would record all seen > atom:ids along with the source-feeds in which they were discovered. > Then, if > another instance of an atom:id is found, the service would determine > if the > current instance came from the same feed as the previous instance. If > so, > then the new entry would be treated as a replacement for the old one. > If > not, the service would re-fetch the feed in which the atom:id was > previously > found and attempt to recover the original entry. If the original can be > recovered, it would be used. If not, then local policy would determine > if > the more recent entry should be deleted, passed on as legitimate, or > rewritten with a new atom:id. (This method relies on the assumption > that the > "authoritative" entry will always be read *before* any "spoof" or > "malicious" entries are read. This may not be a good assumption.) > > Both of these methods require a good bit of work by the aggregator. > While it is completely reasonable for a service like PubSub's to do > this > stuff, it might be considered onerous for desktop clients due to the > increased latency in reporting new entries to users as well as the > increased > processing requirements and network traffic loads. Nonetheless, the > methods > above would allow a service like PubSub's to have greater confidence > that > the correct data was being distributed. > > There remains an issue related to "attribution". Even if the > original source of an entry is retrieved, the aggregator probably must > remember the feed in which the entry's existence was discovered. The > problem > is that you might have someone who is interested in "all entries from > blog > 'A'". In this case, even if the original source of an entry was Blog > 'B', > you should still deliver a copy to the subscriber. We have no syntax at > present to allow the specification of "delivery via" or "alternate > feeds" > (different from rel="alternate") in Atom. Thus, maintaining this data > would > require private extensions to Atom. > > bob wyman > > > [0] "Pinging" is the process by which blog CMS software informs > aggregators > that the blog has been updated. See: http://blo.gs , > http://pingomatic.com/ > etc. > From owner-atom-syntax@mail.imc.org Sat Aug 28 06:07:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06187 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 06:07:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9q6VG045602; Sat, 28 Aug 2004 02:52:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S9q6w6045601; Sat, 28 Aug 2004 02:52:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7S9q5uq045577 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 02:52:05 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 15347 invoked by uid 65534); 28 Aug 2004 09:51:59 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp005) with SMTP; 28 Aug 2004 11:51:59 +0200 X-Authenticated: #1915285 Message-ID: <413055AB.6060800@gmx.de> Date: Sat, 28 Aug 2004 11:51:39 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> CC: Danny Ayers <danny.ayers@gmail.com>, Graham <dtcd@mac.com>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> In-Reply-To: <opsdfq3ciyuvpchu@quark> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Sat, 28 Aug 2004 10:24:15 +0200, Danny Ayers <danny.ayers@gmail.com> > wrote: > >> Bottom line is there are unlikely to be any major problems with the >> string-comparison approach, but in any case such problems can be >> avoided entirely if the IDs are canonical. > > > Exactly. I'd like to understand what class of (unlikely) problems that would solve. Example, please? >> I don't know of a precedent for requiring URI canonicalization, so >> would hesitate to mandate it. But I think the next spec draft ought at >> least say publishers SHOULD use canonical URIs, and based on >> experiences with that the decision can be made on whether a MUST would >> be better. > > > I think SHOULD is enough, but if we get consensus around MUST, that is > great. > >> This is assuming clients SHOULD use string comparison, and MUST >> preserve ids in a form that retains this ability (i.e. within whatever >> encoding is used) if republishing. > > > Yes to both; I think they should. I thought they *MUST* do string comparison. Is there any reason to leave implementors the choice not to do it? Regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 28 06:18:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06638 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 06:18:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SA3kxc047667; Sat, 28 Aug 2004 03:03:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SA3kLS047666; Sat, 28 Aug 2004 03:03:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SA3jvk047653 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 03:03:45 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 77906 invoked by uid 17064); 28 Aug 2004 10:03:46 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.9.20]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <julian.reschke@gmx.de>; 28 Aug 2004 10:03:46 -0000 In-Reply-To: <413055AB.6060800@gmx.de> References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> <413055AB.6060800@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <887F7399-F8D9-11D8-ADE0-000A95D9FA7A@bblfish.net> Cc: Julian Reschke <julian.reschke@gmx.de> From: Henry Story <henry.story@bblfish.net> Subject: Re: URIs vs Strings Date: Sat, 28 Aug 2004 12:03:38 +0200 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SA3kvk047657 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On 28 Aug 2004, at 11:51, Julian Reschke wrote: > > Asbjørn Ulsberg wrote: > >> On Sat, 28 Aug 2004 10:24:15 +0200, Danny Ayers >> <danny.ayers@gmail.com> wrote: >>> Bottom line is there are unlikely to be any major problems with the >>> string-comparison approach, but in any case such problems can be >>> avoided entirely if the IDs are canonical. >> Exactly. > > I'd like to understand what class of (unlikely) problems that would > solve. Example, please? I think it just makes the spec simpler to understand. > >>> I don't know of a precedent for requiring URI canonicalization, so >>> would hesitate to mandate it. But I think the next spec draft ought >>> at >>> least say publishers SHOULD use canonical URIs, and based on >>> experiences with that the decision can be made on whether a MUST >>> would >>> be better. >> I think SHOULD is enough, but if we get consensus around MUST, that >> is great. >>> This is assuming clients SHOULD use string comparison, and MUST >>> preserve ids in a form that retains this ability (i.e. within >>> whatever >>> encoding is used) if republishing. >> Yes to both; I think they should. > > I thought they *MUST* do string comparison. Is there any reason to > leave implementors the choice not to do it? you can go with the weaker version, but it sometimes helps to have more than one protection. The question otherwise is: would it create any undue problems to have the spec be just a little tighter than necessary. Another question I have is: why did the RDF group think it necessary to create a URI reference object [1] when they could have just gone down the canonicalised URI route. Are we missing something? Henry http://bblfish.net/ [1] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference > Regards, Julian > > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From owner-atom-syntax@mail.imc.org Sat Aug 28 06:27:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06961 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 06:27:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SAHCH8050524; Sat, 28 Aug 2004 03:17:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SAHCaR050523; Sat, 28 Aug 2004 03:17:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SAHBO9050507 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 03:17:11 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 18816 invoked by uid 65534); 28 Aug 2004 10:17:06 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp019) with SMTP; 28 Aug 2004 12:17:06 +0200 X-Authenticated: #1915285 Message-ID: <41305BA0.10905@gmx.de> Date: Sat, 28 Aug 2004 12:17:04 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story <henry.story@bblfish.net> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> <413055AB.6060800@gmx.de> <887F7399-F8D9-11D8-ADE0-000A95D9FA7A@bblfish.net> In-Reply-To: <887F7399-F8D9-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Henry Story wrote: >> Asbjørn Ulsberg wrote: >> >>> On Sat, 28 Aug 2004 10:24:15 +0200, Danny Ayers >>> <danny.ayers@gmail.com> wrote: >>> >>>> Bottom line is there are unlikely to be any major problems with the >>>> string-comparison approach, but in any case such problems can be >>>> avoided entirely if the IDs are canonical. >>> >>> Exactly. >> >> >> I'd like to understand what class of (unlikely) problems that would >> solve. Example, please? > > I think it just makes the spec simpler to understand. First of all, it makes the spec more complex, as it adds a new requirement that - as far as I understand - doesn't have any effect on interoperability as long as consumers indeed do string comparisons. So again, if people talk about possible problems without canonicalization, they'd be able to provide an example, right? >> I thought they *MUST* do string comparison. Is there any reason to >> leave implementors the choice not to do it? > > you can go with the weaker version, but it sometimes helps to have more > than one protection. The question otherwise is: would it create any > undue problems to have the spec be just a little tighter than necessary. Well, if people do *not* perform string comparison, IDs that are supposed to be different may compare equal. This seems to be a major problem. > ... Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 28 10:38:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19529 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 10:38:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SESXp0092309; Sat, 28 Aug 2004 07:28:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SESXn6092308; Sat, 28 Aug 2004 07:28:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SESXQ5092281 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 07:28:33 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040828142830.97184.qmail@web41205.mail.yahoo.com> Received: from [67.170.16.28] by web41205.mail.yahoo.com via HTTP; Sat, 28 Aug 2004 07:28:30 PDT Date: Sat, 28 Aug 2004 07:28:30 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: URIs vs Strings To: Henry Story <henry.story@bblfish.net>, Atom Syntax <atom-syntax@imc.org> Cc: Julian Reschke <julian.reschke@gmx.de> In-Reply-To: <887F7399-F8D9-11D8-ADE0-000A95D9FA7A@bblfish.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Henry Story <henry.story@bblfish.net> wrote: > > Another question I have is: why did the RDF group > think it necessary to > create a > URI reference object [1] when they could have just > gone down the > canonicalised URI route. Are we missing something? Because it is an unnecessary burden on producers? Canonicalization is an attempt to protect against consumers implemented by people who don't read the spec. However I don't understand why people seem to think that if consumers won't read the spec producers will. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Aug 28 10:43:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19788 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 10:43:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SEWsc6093102; Sat, 28 Aug 2004 07:32:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SEWswm093101; Sat, 28 Aug 2004 07:32:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SEWrGe093081 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 07:32:54 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc13) with SMTP id <2004082814325101500lrsi1e>; Sat, 28 Aug 2004 14:32:51 +0000 Date: Sat, 28 Aug 2004 08:32:49 -0600 Subject: Re: URIs vs Strings Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <41305BA0.10905@gmx.de> Message-Id: <22EC03BF-F8FF-11D8-91ED-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Saturday, August 28, 2004, at 04:17 AM, Julian Reschke wrote: > So again, if people talk about possible problems without > canonicalization, they'd be able to provide an example, right? > Example: My company has a database full of whatever. I write some code that generates and Atom feed from that data. The company has some sort of rules for dynamically generating IDs based on some immutable data in the database, but we don't actually store the IDs. An example ID is foo:www.geckotribe.com/bar/1/2/3. So far so good. Next, someone at the same company writes some code to output another Atom feed based on the same data (but filtered differently, so a different mix of entries ends up in their feed). They are told the same rules for generating IDs based on data in the database, and their implementation generates IDs like foo:www.GeckoTribe.com/bar/1/2/3. Because of capitalization differences in the domain name portion, the IDs do not match. Because the spec states that ID comparison is to be done character-by-character, my company's rules for generating IDs out of the database SHOULD HAVE specified whether to capitalize or not, but because the spec didn't call this particular point to the attention of the people who wrote the company rules, they didn't put anything about capitalization in those rules, and we ended up with a problem. Recommending canonicalization, and specifying clearly what we mean by canonical form, serves to bring the most likely sticking points to people's attention. It reminds people that they can't simply trust some library that they're using to output URIs to do the right thing--different libraries may do things a little differently. From owner-atom-syntax@mail.imc.org Sat Aug 28 11:12:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21009 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 11:12:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SF4ejD099267; Sat, 28 Aug 2004 08:04:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SF4eoN099266; Sat, 28 Aug 2004 08:04:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SF4dd6099251 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 08:04:40 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040828150437.91976.qmail@web41212.mail.yahoo.com> Received: from [67.170.16.28] by web41212.mail.yahoo.com via HTTP; Sat, 28 Aug 2004 08:04:37 PDT Date: Sat, 28 Aug 2004 08:04:37 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: URIs vs Strings To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org In-Reply-To: <22EC03BF-F8FF-11D8-91ED-003065EA6144@geckotribe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Antone Roundy <antone@geckotribe.com> wrote: > > On Saturday, August 28, 2004, at 04:17 AM, Julian > Reschke wrote: > > So again, if people talk about possible problems > without > > canonicalization, they'd be able to provide an > example, right? > > > Example: > > My company has a database full of whatever. I write > some code that > generates and Atom feed from that data. The company > has some sort of > rules for dynamically generating IDs based on some > immutable data in > the database, but we don't actually store the IDs. > An example ID is > foo:www.geckotribe.com/bar/1/2/3. So far so good. > > Next, someone at the same company writes some code > to output another > Atom feed based on the same data (but filtered > differently, so a > different mix of entries ends up in their feed). > They are told the > same rules for generating IDs based on data in the > database, and their > implementation generates IDs like > foo:www.GeckoTribe.com/bar/1/2/3. > Because of capitalization differences in the domain > name portion, the > IDs do not match. > > Because the spec states that ID comparison is to be > done > character-by-character, my company's rules for > generating IDs out of > the database SHOULD HAVE specified whether to > capitalize or not, but > because the spec didn't call this particular point > to the attention of > the people who wrote the company rules, they didn't > put anything about > capitalization in those rules, and we ended up with > a problem. > Recommending canonicalization, and specifying > clearly what we mean by > canonical form, serves to bring the most likely > sticking points to > people's attention. It reminds people that they > can't simply trust > some library that they're using to output URIs to do > the right > thing--different libraries may do things a little > differently. > > If the morons at your company can't figure out that the fact that IDs must be compared character by character means they can't vary in capitalization from reading the spec what makes you think that they'll pay attention to any rules about canonicalization? Do you really think these people will be able to implement the rules in http://www.intertwingly.net/wiki/pie/PaceCanonicalIds without screwing it up? That is if they bother reading the spec to that degree of detail. Adding this extra complexity to the spec only buys you one thing; it makes the spec writers feel warm and fuzzy. However since this is the only issue holding up IDs I don't see why we can't just compromise on a SHOULD for canonicalizing URIs and move on. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Sat Aug 28 11:56:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23269 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 11:56:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SFjjBX010119; Sat, 28 Aug 2004 08:45:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SFjjhZ010118; Sat, 28 Aug 2004 08:45:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SFjjO6010106 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 08:45:45 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id IAA04175 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 08:45:42 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id IAA06992 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 08:45:42 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Sat, 28 Aug 2004 08:45:42 -0700 Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i7SFjelB016218 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 08:45:41 -0700 (PDT) Date: Sat, 28 Aug 2004 08:45:48 -0700 From: Walter Underwood <wunder@verity.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings Message-ID: <1F505BEC8EDB69C9D26F7076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <20040828142830.97184.qmail@web41205.mail.yahoo.com> References: <20040828142830.97184.qmail@web41205.mail.yahoo.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On Saturday, August 28, 2004 7:28 AM -0700 Dare Obasanjo <kpako@yahoo.com> wrote: > > Canonicalization is an attempt to protect against > consumers implemented by people who don't read the > spec. No, it is allowance for normal humans who make understandable mistakes. Treating URIs as URIs instead of as strings is a quite understandable mistake. So, we protect against that, and Atom implementation are more likely to work. This was said best by John Postel, be conservative in what you generate and generous in what you accept. The most robust approach would require canonical URIs and allow fancy comparisons. The alternative is to spend forever tracking down minor problems in other people's code, code which has already been deployed. Fragile specs are a nightmare. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sat Aug 28 12:24:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25133 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 12:24:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SGFnQe013978; Sat, 28 Aug 2004 09:15:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SGFnjv013977; Sat, 28 Aug 2004 09:15:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SGFmxK013963 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 09:15:49 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 7831 invoked by uid 65534); 28 Aug 2004 16:15:45 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp008) with SMTP; 28 Aug 2004 18:15:45 +0200 X-Authenticated: #1915285 Message-ID: <4130AFA8.60503@gmx.de> Date: Sat, 28 Aug 2004 18:15:36 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood <wunder@verity.com> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <20040828142830.97184.qmail@web41205.mail.yahoo.com> <1F505BEC8EDB69C9D26F7076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <1F505BEC8EDB69C9D26F7076@adsl-64-166-133-243.dsl.snfc21.pacbell.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Walter Underwood wrote: > --On Saturday, August 28, 2004 7:28 AM -0700 Dare Obasanjo > <kpako@yahoo.com> wrote: > >> >> Canonicalization is an attempt to protect against >> consumers implemented by people who don't read the >> spec. > > > No, it is allowance for normal humans who make understandable > mistakes. Treating URIs as URIs instead of as strings is a quite > understandable mistake. > > So, we protect against that, and Atom implementation are > more likely to work. Nope. Canonicalization doesn't guarantee that comparing as "URI" won't break anything, it just makes this scenario less probable. That's why I dislike it -- implementors will possibly be encouraged not to implement comparison as specced, because IDs will be "canonical" anyway. Big mistake. > This was said best by John Postel, be conservative in what > you generate and generous in what you accept. The most robust > approach would require canonical URIs and allow fancy comparisons. That wouldn't work, unless you know beforehand what these "fancy" comparisons indeed are. BTW: being generous in what you accept in this case would mean that you'd possibly get false positives. Is this really what you want? > The alternative is to spend forever tracking down minor problems > in other people's code, code which has already been deployed. > Fragile specs are a nightmare. That's correct. My point being is that the spec will have maximum robustness if it's crystal clear on it's requirements for comparison, and that's it. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 28 12:52:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28674 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 12:52:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SGgjgb018522; Sat, 28 Aug 2004 09:42:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SGgjWL018521; Sat, 28 Aug 2004 09:42:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SGghnF018494 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 09:42:44 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 4439 invoked by uid 65534); 28 Aug 2004 16:42:41 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp002) with SMTP; 28 Aug 2004 18:42:41 +0200 X-Authenticated: #1915285 Message-ID: <4130B5FB.9030106@gmx.de> Date: Sat, 28 Aug 2004 18:42:35 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy <antone@geckotribe.com> CC: atom-syntax@imc.org Subject: Re: URIs vs Strings References: <22EC03BF-F8FF-11D8-91ED-003065EA6144@geckotribe.com> In-Reply-To: <22EC03BF-F8FF-11D8-91ED-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Saturday, August 28, 2004, at 04:17 AM, Julian Reschke wrote: > >> So again, if people talk about possible problems without >> canonicalization, they'd be able to provide an example, right? >> > Example: > > ... Ok, thanks for providing an actual example. My reaction is: this may occur if the developers did not read or do not understand the spec. So whatever we can say about what the *impact* of string comparison is, we should say. On the other hand: if this problem occurs, existing clients will not detect the duplicates; and it should become clear very very quickly that there is a problem that needs to be fixed. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 28 14:59:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04619 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 14:59:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SImpWT039468; Sat, 28 Aug 2004 11:48:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SImp5e039467; Sat, 28 Aug 2004 11:48:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SImnoN039444 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 11:48:50 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 28120 invoked by uid 65534); 28 Aug 2004 18:48:46 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp017) with SMTP; 28 Aug 2004 20:48:46 +0200 X-Authenticated: #1915285 Message-ID: <4130D374.8030507@gmx.de> Date: Sat, 28 Aug 2004 20:48:20 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers <danny.ayers@gmail.com> CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> <413055AB.6060800@gmx.de> <1f2ed5cd04082811454a98439b@mail.gmail.com> In-Reply-To: <1f2ed5cd04082811454a98439b@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Danny Ayers wrote: > The classic: aggregator receives posts with ids > http://example.org/blog1 and HTTP://EXAMPLE.ORG/blog1, believes them > to be different, displays both. And that's what it should do. It's the producer's job to ensure that the IDs make sense. > ... Regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 28 14:59:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04641 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 14:59:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SIjAcJ039008; Sat, 28 Aug 2004 11:45:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SIjAlb039007; Sat, 28 Aug 2004 11:45:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SIj9Vl038999 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 11:45:09 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so57033rnb for <atom-syntax@imc.org>; Sat, 28 Aug 2004 11:45:11 -0700 (PDT) Received: by 10.38.206.45 with SMTP id d45mr715455rng; Sat, 28 Aug 2004 11:45:10 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sat, 28 Aug 2004 11:45:10 -0700 (PDT) Message-ID: <1f2ed5cd04082811454a98439b@mail.gmail.com> Date: Sat, 28 Aug 2004 20:45:10 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: Julian Reschke <julian.reschke@gmx.de> Subject: Re: URIs vs Strings Cc: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>, Graham <dtcd@mac.com>, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <413055AB.6060800@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> <413055AB.6060800@gmx.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SIj9Vl039002 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 11:51:39 +0200, Julian Reschke <julian.reschke@gmx.de> wrote: > Asbjørn Ulsberg wrote: > > > > > On Sat, 28 Aug 2004 10:24:15 +0200, Danny Ayers <danny.ayers@gmail.com> > > wrote: > > > >> Bottom line is there are unlikely to be any major problems with the > >> string-comparison approach, but in any case such problems can be > >> avoided entirely if the IDs are canonical. > > > > > > Exactly. > > I'd like to understand what class of (unlikely) problems that would > solve. Example, please? The classic: aggregator receives posts with ids http://example.org/blog1 and HTTP://EXAMPLE.ORG/blog1, believes them to be different, displays both. > >> This is assuming clients SHOULD use string comparison, and MUST > >> preserve ids in a form that retains this ability (i.e. within whatever > >> encoding is used) if republishing. > > > > > > Yes to both; I think they should. > > I thought they *MUST* do string comparison. Is there any reason to leave > implementors the choice not to do it? I left it down as SHOULD because it doesn't really impact anything outside of the app (except perhaps for the end user). I personally wouldn't have a problem with it being MUST in the spec. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Aug 28 14:59:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04680 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 14:59:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SIr39L040243; Sat, 28 Aug 2004 11:53:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SIr307040242; Sat, 28 Aug 2004 11:53:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SIr2gj040233 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 11:53:02 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail30-en1.mac.com (webmail30-en1 [10.13.10.130]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7SIr5ro028260; Sat, 28 Aug 2004 11:53:05 -0700 (PDT) Received: from webmail30 (localhost.mac.com [127.0.0.1]) by webmail30-en1.mac.com (8.12.6/8.12.6) with ESMTP id i7SIr4i7001035; Sat, 28 Aug 2004 11:53:04 -0700 (PDT) Message-ID: <1275995.1093719184773.JavaMail.dtcd@mac.com> Date: Sat, 28 Aug 2004 14:53:04 -0400 From: Graham Parks <dtcd@mac.com> To: Antone Roundy <antone@geckotribe.com> Subject: Re: URIs vs Strings Cc: atom-syntax@imc.org in-reply-to: <22EC03BF-F8FF-11D8-91ED-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <22EC03BF-F8FF-11D8-91ED-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 28 Aug 2004, at 7:32 am, Antone Roundy wrote: > They are told the same rules for generating IDs based on data in the database I find it more likely that if this step happens at all, it'll happen correctly. Even more likely is that the step won't happen, and they'll pick different ids, which canonicalization won't save you from. In other words the chain of events that causes two people to pick different ids that happen to be the same canonically is so small I don't see the point in accounting for it. Graham From owner-atom-syntax@mail.imc.org Sat Aug 28 15:02:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04833 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 15:02:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SItTWc040784; Sat, 28 Aug 2004 11:55:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SItTp6040783; Sat, 28 Aug 2004 11:55:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SItSxl040775 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 11:55:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail30-en1.mac.com (webmail30-en1 [10.13.10.130]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7SItVIT019966; Sat, 28 Aug 2004 11:55:31 -0700 (PDT) Received: from webmail30 (localhost.mac.com [127.0.0.1]) by webmail30-en1.mac.com (8.12.6/8.12.6) with ESMTP id i7SItVi7001076; Sat, 28 Aug 2004 11:55:31 -0700 (PDT) Message-ID: <15068698.1093719331209.JavaMail.dtcd@mac.com> Date: Sat, 28 Aug 2004 14:55:31 -0400 From: Graham Parks <dtcd@mac.com> To: Bjoern Hoehrmann <derhoermi@gmx.net> Subject: Re: PaceIdConstruct2 created Cc: "'Atom Syntax'" <atom-syntax@imc.org> in-reply-to: <413339e4.199654337@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> <413339e4.199654337@smtp.bjoern.hoehrmann.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 28 Aug 2004, at 1:37 am, Bjoern Hoehrmann wrote: > I am opposed to such conformance requirements that require universal > knowledge to determine conformance or such that allow anyone to make > my future Atom content non-conforming. Yeah. That probably needs to be captured in the spec. It's still an improvement on just saying "universally unique". >> Changes to the content or location of the resource MUST NOT >> change the identifier. All Atom Documents published by the same entity >> MUST use the same identifier for each respective resource they >> publish. > > I can't make sense of the last sentence here, what does it mean? You MUST always use the same ids for your own entries. If you're republishing someone else's (say, a feed of search engine results), it's only SHOULD. >> A system that accepts input in Atom format that it subsequently >> outputs >> in Atom format SHOULD pass through the values of all identifiers. > > Why is this a SHOULD? What are cases where it would be acceptable or > even desired to behave that way? If someone is subscribed to a blog feed and a feed of search engine results, and entries from that blog show up in the search results, its beneficial to give the aggregator a hint of which entries are the same. >> "atom:id" is an Identification construct that identifies instances of >> the same entry. atom:entry elements MUST contain an atom:id element, >> but MUST NOT contain more than one. Two entries may be considered >> instances of one another when their atom:id elements contain same >> identifier, but implementations MUST NOT assume they contain the same >> content. > > What does it mean for an implementation to assume that two entries > contain the same content? What does it mean not to do that? Without that sentence, someone might assume that when they find an entry with the same identifier as one they have previously seen, they may assume the content is the same and has not changed at all. > There is not much point in discussing when two IDs are considered > equivalent if that does > not yield in clear implications for Atom implementations. "Two entries may be considered instances of one another when their atom:id elements contain same identifier, but implementations MUST NOT assume they contain the same content." That's a pretty clear implication, isn't it? The implementation knows that two entries are versions of one another, but does not know they contain the same content. After that, it's up to the application to decide whether to only show the most recent, or show a list of all versions, or whatever it chooses. > Say there are two feed which are equivalent as defined by XML C14N > except that the IDs in the document use a different host name, are > implementations that treat the entries in the feeds as equivalent > non-conforming? Same content, different ids? The answer is of course, yes, but I also think it's outside the scope of the spec, and certainly of the atom:id spec. Can someone with more spec writing experience than me needs to answer this? > Say there are two entries for which human testing determines them as > very different yet they have the same ID, are implementations that > treat > the entries as very different as opposed to treating one entry as a > modified version of the other entry non-conforming? I said they "may" be considered versions of one another, not must. I don't think there's any need to be more explicit than that. Graham From owner-atom-syntax@mail.imc.org Sat Aug 28 15:02:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04858 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 15:02:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SIuBO4040941; Sat, 28 Aug 2004 11:56:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SIuBgH040940; Sat, 28 Aug 2004 11:56:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SIuBae040933 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 11:56:11 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from webmail30-en1.mac.com (webmail30-en1 [10.13.10.130]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7SIuEao021226; Sat, 28 Aug 2004 11:56:14 -0700 (PDT) Received: from webmail30 (localhost.mac.com [127.0.0.1]) by webmail30-en1.mac.com (8.12.6/8.12.6) with ESMTP id i7SIuDi7001095; Sat, 28 Aug 2004 11:56:14 -0700 (PDT) Message-ID: <10879249.1093719373833.JavaMail.dtcd@mac.com> Date: Sat, 28 Aug 2004 14:56:13 -0400 From: Graham Parks <dtcd@mac.com> To: Robert Sayre <mint@franklinmint.fm> Subject: Re: PaceIdConstruct2 created Cc: "'Atom Syntax'" <atom-syntax@imc.org> in-reply-to: <41300E12.50909@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> <41300E12.50909@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 27 Aug 2004, at 9:46 pm, Robert Sayre wrote: >> Identification Constructs convey an identifier that is used to >> associate different instances of the same resource. Whenever a >> resource appears in an Atom Document, its identifier SHOULD be the >> same as any other times it has appeared in an Atom Document, and MUST >> NOT be the same as the identifier currently or formerly used for any >> other Atom resource. Changes to the content or location of the >> resource MUST NOT change the identifier. > > You seem to be circling the definition of URIs and Resources. You've > failed to get your intent across (IMHO), but I couldn't do better. Yes. The first para describes them only conceptually, with the URI stuff left until the second and third. Similarly "resource" is left open because it literally defines a range of resources. The problem is that entries and feeds and have not been defined yet, so the Identification Construct can't be tied to entries and feeds until their specs. This points to a larger problem with the structure of the whole spec, I think. >> All Atom Documents published by the same entity MUST use the same >> identifier for each respective resource they publish. >> The content of an Identification Construct MUST be an absolute URI >> (see RFC 2396), > > -1. URIs with fragments should be ok. Nitpick? Yes. OK. I'm not completely au fait with that aspect of URI terminology. > > which MAY come from any scheme. > > This statement is redundant. Probably. >> When the URI comes from a resolvable scheme, it MAY resolve to any >> resource, and MAY not resolve successfully. Implementations therefore >> MUST NOT assume there is any particular relationship between the >> resource the identifier belongs to and any resource it resolves to. > > -1. If the scheme is resolvable, there sure is a relationship, even if > it is "404 Not Found", for example. We don't get to define schemes. The intention here is to avoid implementations assuming HTTP ids are permalinks. I don't think I'm redefining schemes - sure, there's a relationship between the URI and the web page, but that does not imply a relationship between the Atom entry and the web page. > Since the format spec defines Atom in terms of the XML Infoset, it > would be best to to state that IDs are identical only when their > Infoset props are identical (i.e. char-by-char). Yeah. Graham From owner-atom-syntax@mail.imc.org Sat Aug 28 15:12:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06069 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 15:12:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJ2lDq043999; Sat, 28 Aug 2004 12:02:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJ2l4H043998; Sat, 28 Aug 2004 12:02:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJ2kI3043932 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:02:46 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so57318rnb for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:02:45 -0700 (PDT) Received: by 10.38.1.72 with SMTP id 72mr716562rna; Sat, 28 Aug 2004 12:02:45 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sat, 28 Aug 2004 12:02:45 -0700 (PDT) Message-ID: <1f2ed5cd0408281202521612b0@mail.gmail.com> Date: Sat, 28 Aug 2004 21:02:45 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: Julian Reschke <julian.reschke@gmx.de> Subject: Re: URIs vs Strings Cc: Walter Underwood <wunder@verity.com>, Atom Syntax <atom-syntax@imc.org> In-Reply-To: <4130AFA8.60503@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040828142830.97184.qmail@web41205.mail.yahoo.com> <1F505BEC8EDB69C9D26F7076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <4130AFA8.60503@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > That's why I dislike it -- implementors will possibly be encouraged not > to implement comparison as specced, because IDs will be "canonical" > anyway. Big mistake. I'm curious, how might the implementors do the comparisons that is going to less strict that string comparison? > > This was said best by John Postel, be conservative in what > > you generate and generous in what you accept. The most robust > > approach would require canonical URIs and allow fancy comparisons. > > That wouldn't work, unless you know beforehand what these "fancy" > comparisons indeed are. Presumably the 'ladder' in RFC 2396. > BTW: being generous in what you accept in this case would mean that > you'd possibly get false positives. Is this really what you want? There are no exceptions. Just situations in which it doesn't apply ;-) > > The alternative is to spend forever tracking down minor problems > > in other people's code, code which has already been deployed. > > Fragile specs are a nightmare. > > That's correct. My point being is that the spec will have maximum > robustness if it's crystal clear on it's requirements for comparison, > and that's it. Maybe not robustness, but almost certainly utility. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Aug 28 15:13:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06244 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 15:13:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJ6S5h046508; Sat, 28 Aug 2004 12:06:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJ6SXW046507; Sat, 28 Aug 2004 12:06:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SJ6RtW046435 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:06:27 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 28501 messnum 3871649 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 28 Aug 2004 19:06:25 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail08.svc.cra.dublin.eircom.net (qp 28501) with SMTP; 28 Aug 2004 19:06:25 -0000 Message-ID: <4130D7AF.4060603@dehora.net> Date: Sat, 28 Aug 2004 20:06:23 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: URIs vs Strings References: <20040828150437.91976.qmail@web41212.mail.yahoo.com> In-Reply-To: <20040828150437.91976.qmail@web41212.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > If the morons at your company can't figure out that > the fact that IDs must be compared character by > character means they can't vary in capitalization from > reading the spec what makes you think that they'll pay > attention to any rules about canonicalization? "If the morons at your company can't figure out that the fact that IDs are URIs which means they can vary in comparison from scheme to scheme, what makes you think that they'll pay attention to any rules about string comparison?" This thread is pointless. URIs v Strings is the wrong technical deathmatch. cheers Bill From owner-atom-syntax@mail.imc.org Sat Aug 28 15:19:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06831 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 15:19:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJ8n2K048157; Sat, 28 Aug 2004 12:08:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJ8nFq048156; Sat, 28 Aug 2004 12:08:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SJ8mSb048064 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:08:48 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 86196 messnum 4178631 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 28 Aug 2004 19:08:46 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail00.svc.cra.dublin.eircom.net (qp 86196) with SMTP; 28 Aug 2004 19:08:46 -0000 Message-ID: <4130D83C.5020409@dehora.net> Date: Sat, 28 Aug 2004 20:08:44 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> <413055AB.6060800@gmx.de> <1f2ed5cd04082811454a98439b@mail.gmail.com> <4130D374.8030507@gmx.de> In-Reply-To: <4130D374.8030507@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Danny Ayers wrote: > >> The classic: aggregator receives posts with ids >> http://example.org/blog1 and HTTP://EXAMPLE.ORG/blog1, believes them >> to be different, displays both. > > > And that's what it should do. > > It's the producer's job to ensure that the IDs make sense. How do they not make sense? cheers Bill From owner-atom-syntax@mail.imc.org Sat Aug 28 15:23:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07069 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 15:23:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJGY6f053407; Sat, 28 Aug 2004 12:16:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJGYfS053406; Sat, 28 Aug 2004 12:16:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SJGXQO053306 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:16:33 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 28724 invoked by uid 65534); 28 Aug 2004 19:16:30 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp018) with SMTP; 28 Aug 2004 21:16:30 +0200 X-Authenticated: #1915285 Message-ID: <4130D9F4.90507@gmx.de> Date: Sat, 28 Aug 2004 21:16:04 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers <danny.ayers@gmail.com> CC: Walter Underwood <wunder@verity.com>, Atom Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <20040828142830.97184.qmail@web41205.mail.yahoo.com> <1F505BEC8EDB69C9D26F7076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <4130AFA8.60503@gmx.de> <1f2ed5cd0408281202521612b0@mail.gmail.com> In-Reply-To: <1f2ed5cd0408281202521612b0@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Danny Ayers wrote: >>That's why I dislike it -- implementors will possibly be encouraged not >>to implement comparison as specced, because IDs will be "canonical" >>anyway. Big mistake. > > > I'm curious, how might the implementors do the comparisons that is > going to less strict that string comparison? Any comparison that involves URI-specific knowledge will be less strict. >>>This was said best by John Postel, be conservative in what >>>you generate and generous in what you accept. The most robust >>>approach would require canonical URIs and allow fancy comparisons. >> >>That wouldn't work, unless you know beforehand what these "fancy" >>comparisons indeed are. > > > Presumably the 'ladder' in RFC 2396. s/2396/2396bis/ The "ladder" does not specify scheme-specific equivalences as they are outside the scope of RFC2396bis. > ... >>>The alternative is to spend forever tracking down minor problems >>>in other people's code, code which has already been deployed. >>>Fragile specs are a nightmare. >> >>That's correct. My point being is that the spec will have maximum >>robustness if it's crystal clear on it's requirements for comparison, >>and that's it. > > > Maybe not robustness, but almost certainly utility. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 28 15:23:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07089 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 15:23:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJFRmJ052700; Sat, 28 Aug 2004 12:15:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJFR5m052699; Sat, 28 Aug 2004 12:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJFPhB052631 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:15:26 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by mail.pubsub.com (Postfix) with ESMTP id E759C171D76; Sat, 28 Aug 2004 15:15:20 -0400 (EDT) Reply-To: <bobwyman@pubsub.com> From: "Bob Wyman" <bobwyman@pubsub.com> To: "'Henry Story'" <henry.story@bblfish.net>, "'Atom Syntax'" <atom-syntax@imc.org> Subject: RE: A method for verifying cross-feed atom:id uses Date: Sat, 28 Aug 2004 15:17:42 -0400 Organization: PubSub Concepts, Inc. Message-ID: <000501c48d33$b155b850$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <6D33E14C-F8D6-11D8-ADE0-000A95D9FA7A@bblfish.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Henry Story wrote: > First of all notice that if someone is maliciously changing > id's they could also maliciously change the source-feed. It's not "changing" ids, it's "copying" or "spoofing" ids that's the problem.. In any case, the fact that people can copy an id and change the source feed is one of the reasons that I contend that ID's should be feed specific -- yet allowed to appear in multiple feeds. If you look carefully at how we use the "ps:source-feed" element at PubSub.com, you'll realize that whenever we "import" or "copy" an entry into an aggregate feed, we copy it's source attribution. One can then use the combination of id+source is to disambiguate or verify entries. I believe this is the proper behavior and all processes that construct aggregate feeds should do the same. Only what they should be doing is including the feed's atom:head inside atom:entry, instead of ps:source-feed. Given this practice, it becomes possible for us to do what I suggested in my earlier mail: i.e. use the appearance of a previously unseen copied element to trigger a rescan of the source feed. i.e. treat "foreign" elements in a feed in the same way one would treat a "ping" message. Using the procedure above and as described in my earlier message, it becomes possible to serve a number of needs and varying levels of "security" concerns. For instance, if you trust a particular aggregate feed author, you could simply accept that any imported entries are faithful replications of their originals -- you can save time and bandwidth by not tracking down the source. On the other hand, if you are "paranoid" (as a service like PubSub should be), then you would go to the extra trouble of verifying the entries prior to passing them on. The mechanism I propose has the nice attribute of making it unnecessary to do what has often been suggested: i.e. providing a means to mark a feed as "original" or "aggregate." By marking each imported entry with information about its source, the distinction between an original entry and an imported entry makes it unnecessary to mark the feed itself. >I think there are many other ways to do this also. I would appreciate it if you could describe at least a few more of the "many other ways" that you know of. You propose: > a feed is just a pointer to a bunch of entries... > Each entry is a resource (REST), where we can > find all the information about the entry itself. This would work, technically, however, I don't think it is likely to become accepted practice since it would result in quite a few additional network roundtrips. The feed has the nice property of gathering entries together so that they can be retrieved with an economy of network operations. Admittedly, what I'm proposing in my "method" is that services like PubSub actually do additional work to verify entries. However, this work is optional and is not required of *all* processors of feeds -- as would be the case in your proposal. What you're proposing is a good "model" for how the system should work, however, I'm afraid that a direct implementation of the model isn't the right thing to do. The "extra-model" operation of copying entries into the feed, even if they exist as resources on the web, is necessary as a practicle means of making the reading of collections of entries more convenient and less complex for the average client developer. Or, have I not properly understood what you propose? bob wyman From owner-atom-syntax@mail.imc.org Sat Aug 28 15:39:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08102 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 15:39:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJUpL4062294; Sat, 28 Aug 2004 12:30:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJUpMx062290; Sat, 28 Aug 2004 12:30:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SJUnAu062211 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:30:50 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 27404 invoked by uid 65534); 28 Aug 2004 19:30:46 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp007) with SMTP; 28 Aug 2004 21:30:46 +0200 X-Authenticated: #1915285 Message-ID: <4130DD53.5030409@gmx.de> Date: Sat, 28 Aug 2004 21:30:27 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> <413055AB.6060800@gmx.de> <1f2ed5cd04082811454a98439b@mail.gmail.com> <4130D374.8030507@gmx.de> <4130D83C.5020409@dehora.net> In-Reply-To: <4130D83C.5020409@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > Julian Reschke wrote: > >> >> Danny Ayers wrote: >> >>> The classic: aggregator receives posts with ids >>> http://example.org/blog1 and HTTP://EXAMPLE.ORG/blog1, believes them >>> to be different, displays both. >> >> >> >> And that's what it should do. >> >> It's the producer's job to ensure that the IDs make sense. > > > How do they not make sense? They didn't make sense in that they were supposed to be equal, but weren't. If the spec states that recipients compare IDs as strings, producers will have to take care of this if they intend to produce two IDs that are supposed to compare equal. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 28 16:00:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09394 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:00:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJbOUN066241; Sat, 28 Aug 2004 12:37:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJbOfS066240; Sat, 28 Aug 2004 12:37:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJbOmu066200 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:37:24 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7SJbJh8008311; Sat, 28 Aug 2004 15:37:19 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOZ42512 (AUTH bob@wyman.us); Sat, 28 Aug 2004 15:37:18 -0400 (EDT) Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "'Danny Ayers'" <danny.ayers@gmail.com>, "'Julian Reschke'" <julian.reschke@gmx.de> Cc: "'Walter Underwood'" <wunder@verity.com>, "'Atom Syntax'" <atom-syntax@imc.org> Subject: RE: URIs vs Strings Date: Sat, 28 Aug 2004 15:39:40 -0400 Message-ID: <000601c48d36$c2b94a50$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <1f2ed5cd0408281202521612b0@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Danny Ayers wrote: > I'm curious, how might the implementors do the comparisons > that is going to less strict that string comparison? Here is an example: (No, the following is *not* anti-Microsoft...) Everyone is aware that Windows systems are typically much more liberal in string matches than are Unix/Linux based systems when it comes to case-sensitivity. Thus, Windows coders will often create string keys in their databases which do case-insensitive matching by default while folk in a number of other environments will often create case-sensitive keys instead. The problem comes when someone who *has read* the spec tries to implement it correctly. The reader will say: "Ok, I can't use the special URI-type provided by my fancy database for this key. What I must use is a simple string type (varchar?) since I need character-by-character comparison." Then, newly discovered atom:id's are tested for uniqueness by doing a lookup in the database -- using a string key. All sorts of problems will arise if the string key is case-insensitive. This sort of thing happens all the time -- even when "working" code is moved from one system to another or a database is changed while code is not changed. (i.e. if you access data via ODBC or JDBC, you probably haven't written all sorts of code to verify the index definitions when you attach to a new database...) So, this has been an example of someone trying to do the "Right Thing" but getting bitten by non-canonicalized strings. Also, don't forget that second part about the database being changed after working code has been proven on an earlier database... Even if the original author did the right thing, the system can be broken by a later maintainer not being aware of the impact of changes in database behavior defaults. If atom:id is a canonicalized URI, the problems above are much less likely to occur. bob wyman From owner-atom-syntax@mail.imc.org Sat Aug 28 16:03:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09608 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:03:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJodGU074555; Sat, 28 Aug 2004 12:50:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJod7n074554; Sat, 28 Aug 2004 12:50:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SJoc7c074490 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:50:38 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 30041 invoked by uid 65534); 28 Aug 2004 19:50:36 -0000 Received: from pD9E514A2.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.20.162) by mail.gmx.net (mp013) with SMTP; 28 Aug 2004 21:50:36 +0200 X-Authenticated: #1915285 Message-ID: <4130E1FD.1010600@gmx.de> Date: Sat, 28 Aug 2004 21:50:21 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Atom Syntax'" <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <000601c48d36$c2b94a50$6400a8c0@wyman.us> In-Reply-To: <000601c48d36$c2b94a50$6400a8c0@wyman.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Bob Wyman wrote: > ... > If atom:id is a canonicalized URI, the problems above are much > less likely to occur. This is a good story; and I agree that it can happen. However, if the problem is case-sensitivity it escapes me how canonicalization will solve it. Consider: http://example.com/FooBar http://Example.Com/foobar http://EXAMPLE.COM/FooBar Under canonicalization, there'd still be two different IDs, although all of these would compare equal in a caseless comparison. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Aug 28 16:04:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09646 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:04:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJka05072059; Sat, 28 Aug 2004 12:46:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJkas4072058; Sat, 28 Aug 2004 12:46:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJkYCt072045 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:46:35 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7SJkgYu030119 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:46:46 -0400 Message-ID: <4130E11B.3000600@intertwingly.net> Date: Sat, 28 Aug 2004 15:46:35 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax <atom-syntax@imc.org> Subject: New AtomPubIssuesList for 2004/08/28 References: <412B23C4.9010602@intertwingly.net> In-Reply-To: <412B23C4.9010602@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Sam Ruby wrote: Two new topics for this round, first content elements (tile, summary, content): PaceContentAsTextOrHtml PaceContentSrc PaceNukeMultipart PaceSimpleContentType And then person elements (author, contributor): PacePersonConstructs PacePersonLinks PacePersonRef After two separate attempts to gain consensus on dates, the new approach is to look at this one element at a time - with the request that we look at each independently - i.e., without presuming anything about whether any another date proposal will be accepted or rejected. First up is the one that attained the most sponsors: PaceDateUpdated It seems to me that we can take a similar approach with the link element. While there still are a diverging ideas on the overall approach, it seems like there might be consensus on expelling "service.*" from the values of rel in the syndication format: PaceServiceElement Finally, something for people interested in the protocol, two separate proposals for creating a "design team" which focuses specifically on protocol issues: PaceProtocolDesignTeam PaceProtocolDesignTeam2 - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Aug 28 16:10:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10082 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:10:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJxLLO079648; Sat, 28 Aug 2004 12:59:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJxLnL079647; Sat, 28 Aug 2004 12:59:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJxKm8079628 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:59:20 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7SJxWCe030634 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:59:32 -0400 Message-ID: <4130E41C.4000809@intertwingly.net> Date: Sat, 28 Aug 2004 15:59:24 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax <atom-syntax@imc.org> Subject: comments on PaceProtocolDesignTeam/PaceProtocolDesignTeam2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Overall, both PaceProtocolDesignTeam and PaceProtocolDesignTeam2 are too open ended for my tastes. My biggest concern is that the protocol feels less "complete" than the format. As a specific example, I would like to be able to identify with precision which parts of the following are conformant with the specification, are permissable vendor extensions, or are incompatible with the specification: http://sixapart.com/developers/atom/typepad/ - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Aug 28 16:11:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10208 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:11:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SJfm6q068908; Sat, 28 Aug 2004 12:41:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SJfmsi068907; Sat, 28 Aug 2004 12:41:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SJflZd068875 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 12:41:48 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 410 invoked from network); 28 Aug 2004 19:41:49 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 28 Aug 2004 19:41:49 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <4130E004.2090108@internetalchemy.org> Date: Sat, 28 Aug 2004 20:41:56 +0100 From: Ian Davis <iand@internetalchemy.org> User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bobwyman@pubsub.com CC: "'Henry Story'" <henry.story@bblfish.net>, "'Atom Syntax'" <atom-syntax@imc.org> Subject: Re: A method for verifying cross-feed atom:id uses References: <000501c48d33$b155b850$6400a8c0@wyman.us> In-Reply-To: <000501c48d33$b155b850$6400a8c0@wyman.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 28/08/2004 20:17, Bob Wyman wrote: > In any case, the fact that people can copy an id and change the > source feed is one of the reasons that I contend that ID's should be > feed specific -- yet allowed to appear in multiple feeds. If you look > carefully at how we use the "ps:source-feed" element at PubSub.com, > you'll realize that whenever we "import" or "copy" an entry into an > aggregate feed, we copy it's source attribution. One can then use the > combination of id+source is to disambiguate or verify entries. I believe > this is the proper behavior and all processes that construct aggregate > feeds should do the same. Only what they should be doing is including > the feed's atom:head inside atom:entry, instead of ps:source-feed. +1 to feed-local ids plus source attribution. Ian From owner-atom-syntax@mail.imc.org Sat Aug 28 16:22:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10760 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:22:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKCWcK087264; Sat, 28 Aug 2004 13:12:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKCW3U087263; Sat, 28 Aug 2004 13:12:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SKCUeB087241 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:12:31 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 9592 invoked from network); 28 Aug 2004 20:12:32 -0000 Received: from cpc2-nthc3-5-0-cust215.nrth.cable.ntl.com (HELO ?10.10.10.81?) (213.104.222.215) by relay.pair.com with SMTP; 28 Aug 2004 20:12:32 -0000 X-pair-Authenticated: 213.104.222.215 Message-ID: <4130E738.8070207@internetalchemy.org> Date: Sat, 28 Aug 2004 21:12:40 +0100 From: Ian Davis <iand@internetalchemy.org> User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke <julian.reschke@gmx.de> CC: bob@wyman.us, "'Atom Syntax'" <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <000601c48d36$c2b94a50$6400a8c0@wyman.us> <4130E1FD.1010600@gmx.de> In-Reply-To: <4130E1FD.1010600@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 28/08/2004 20:50, Julian Reschke wrote: > http://example.com/FooBar > http://Example.Com/foobar > http://EXAMPLE.COM/FooBar > > Under canonicalization, there'd still be two different IDs, although all > of these would compare equal in a caseless comparison. Yes, case-sensitive character comparisons (i.e. octet comparisons) will result in no false positives when compared with full URI and scheme comparison. Case-insentive comparisons will conflate ids that are different under the URI rules. So, +1 (again) to case-sensitive character id comparisons Ian From owner-atom-syntax@mail.imc.org Sat Aug 28 16:28:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11010 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:28:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKJuRR089741; Sat, 28 Aug 2004 13:19:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKJuR3089740; Sat, 28 Aug 2004 13:19:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKJu3s089732 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:19:56 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7SKJbh8014449; Sat, 28 Aug 2004 16:19:37 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOZ53279 (AUTH bob@wyman.us); Sat, 28 Aug 2004 16:19:36 -0400 (EDT) Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "'Julian Reschke'" <julian.reschke@gmx.de>, <bob@wyman.us> Cc: "'Atom Syntax'" <atom-syntax@imc.org> Subject: RE: URIs vs Strings Date: Sat, 28 Aug 2004 16:21:57 -0400 Message-ID: <000c01c48d3c$ab5bc990$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4130E1FD.1010600@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Julian Reschke wrote: > This is a good story; and I agree that it can happen. Thanks. >Consider: > http://example.com/FooBar > http://Example.Com/foobar > http://EXAMPLE.COM/FooBar > Under canonicalization, there'd still be two different IDs, although > all of these would compare equal in a caseless comparison. Your example is incomplete. There are 2^4 semantically-equivalent ways to capitalize "http". There are 2^10 semantically-equivalent ways to capitalize "example.com" and 2^14 semantically-equivalent ways to capitalize "http://example.com/". Canonicalization reduces all these possibilities to only *one way*. I see the elimination of (2^14 -1) possible ways to confuse a character-by-character comparison as a significant reduction in the opportunity to make mistakes. It is not a "solution"; however, it is a major step in the right direction. Additionally, there are at least 2^6 different ways to encode "FooBar" when in a path if one treats path as a URI component rather than as a string. Canonicalization only gives us one correct way to encode "FooBar" as a string. This reduction in variety is a good thing and should result in some improvement in the overall consistency of Atom processing. bob wyman From owner-atom-syntax@mail.imc.org Sat Aug 28 16:44:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11940 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:44:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKTAfc092886; Sat, 28 Aug 2004 13:29:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKTA7v092885; Sat, 28 Aug 2004 13:29:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKT9bc092821 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:29:10 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id E2B1C7C1EE; Sat, 28 Aug 2004 23:19:26 +0200 (CEST) Date: Sat, 28 Aug 2004 22:32:03 +0200 To: "Graham Parks" <dtcd@mac.com>, "Bjoern Hoehrmann" <derhoermi@gmx.net> Subject: Re: PaceIdConstruct2 created Cc: "'Atom Syntax'" <atom-syntax@imc.org> References: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> <413339e4.199654337@smtp.bjoern.hoehrmann.de> <15068698.1093719331209.JavaMail.dtcd@mac.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdglzptduvpchu@quark> In-Reply-To: <15068698.1093719331209.JavaMail.dtcd@mac.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 14:55:31 -0400, Graham Parks <dtcd@mac.com> wrote: > You MUST always use the same ids for your own entries. If you're > republishing someone else's (say, a feed of search engine results), > it's only SHOULD. Why only SHOULD for republishing? Is it okay to change the title and content of the entry as well? If not, why can atom:id change, but nothing else? > Without that sentence, someone might assume that when they find an > entry with the same identifier as one they have previously seen, they > may assume the content is the same and has not changed at all. Well, that may be the case too. It's up to other parts of the entry (e.g. a 'modified' date) to give notification about whether the entry has changed or not. I think atom:id should be silent about that issue. > I said they "may" be considered versions of one another, not must. I > don't think there's any need to be more explicit than that. But is it necessary to mention at all? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 16:45:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12020 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:45:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKVQ5f093563; Sat, 28 Aug 2004 13:31:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKVQlu093562; Sat, 28 Aug 2004 13:31:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKVPFa093543 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:31:26 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id D859D7C1EE; Sat, 28 Aug 2004 23:21:45 +0200 (CEST) To: "Julian Reschke" <julian.reschke@gmx.de> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> <413055AB.6060800@gmx.de> <1f2ed5cd04082811454a98439b@mail.gmail.com> <4130D374.8030507@gmx.de> Message-ID: <opsdgl3lgcuvpchu@quark> Date: Sat, 28 Aug 2004 22:34:23 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <4130D374.8030507@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 20:48:20 +0200, Julian Reschke <julian.reschke@gmx.de> wrote: > It's the producer's job to ensure that the IDs make sense. And you don't think c14n is a step in the right direction there? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 16:46:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12069 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:46:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKYjBc094463; Sat, 28 Aug 2004 13:34:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKYjIW094462; Sat, 28 Aug 2004 13:34:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKYiAn094433 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:34:44 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 7CB907C1EE; Sat, 28 Aug 2004 23:25:04 +0200 (CEST) To: "Dare Obasanjo" <kpako@yahoo.com> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <20040828142830.97184.qmail@web41205.mail.yahoo.com> Message-ID: <opsdgl84n6uvpchu@quark> Date: Sat, 28 Aug 2004 22:37:42 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20040828142830.97184.qmail@web41205.mail.yahoo.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 07:28:30 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> wrote: > Because it is an unnecessary burden on producers? Bah! How difficult is it, really? > Canonicalization is an attempt to protect against consumers > implemented by people who don't read the spec. Partly, yes. Why shouldn't we have that protection, when it's very likely it will help? > However I don't understand why people seem to think that if > consumers won't read the spec producers will. Good question. Nonetheless, requiring or recommending c14n for producers help. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 16:46:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12125 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:46:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKcNdh095767; Sat, 28 Aug 2004 13:38:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKcNem095766; Sat, 28 Aug 2004 13:38:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKcN5p095756 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:38:23 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C19xr-0004CH-GQ for atom-syntax@imc.org; Sat, 28 Aug 2004 20:38:19 +0000 Message-ID: <4130ED3D.6070308@franklinmint.fm> Date: Sat, 28 Aug 2004 16:38:21 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax <atom-syntax@imc.org> Subject: PaceProtocolDesignTeam Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit The last reading of consensus we had was here: http://www.imc.org/atom-syntax/mail-archive/msg07601.html The consensus was "overwhelming", not "rough", and there is a *very large* amount of working code to support it. This Pace was drafted to reflect the co-chairs' estimation of consensus. I ask that the co-chairs point to the official record of this WG (this list), and identify messages that advocate something other than REST-with-4-verbs as the primary interface for the Atom protocol. I would also like to know why these messages constitute a body of evidence sufficient to move consensus from "overwhelming", right past "rough", to "none." Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 16:49:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12307 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:49:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKfv1s097323; Sat, 28 Aug 2004 13:41:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKfvBZ097322; Sat, 28 Aug 2004 13:41:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKfuhx097301 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:41:57 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2D7F97C1EE; Sat, 28 Aug 2004 23:32:17 +0200 (CEST) To: "Julian Reschke" <julian.reschke@gmx.de> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <20040828142830.97184.qmail@web41205.mail.yahoo.com> <1F505BEC8EDB69C9D26F7076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <4130AFA8.60503@gmx.de> <1f2ed5cd0408281202521612b0@mail.gmail.com> <4130D9F4.90507@gmx.de> Message-ID: <opsdgmjagsuvpchu@quark> Date: Sat, 28 Aug 2004 22:43:48 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <4130D9F4.90507@gmx.de> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 21:16:04 +0200, Julian Reschke <julian.reschke@gmx.de> wrote: > Any comparison that involves URI-specific knowledge will be less strict. Who has said anything about URI scheme-specific comparison? Producers know which URI scheme they provide in atom:id's. They should then know what it takes to canonicalize them. Consumers should compare them char-by-char no matter what. Where does the URI scheme-specific comparison come into play? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 16:52:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12425 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:52:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKkBYv098700; Sat, 28 Aug 2004 13:46:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKkBBd098699; Sat, 28 Aug 2004 13:46:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKkAtF098673 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:46:11 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id F273F7C1EE; Sat, 28 Aug 2004 23:36:30 +0200 (CEST) To: "Dare Obasanjo" <kpako@yahoo.com> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <20040828150437.91976.qmail@web41212.mail.yahoo.com> Message-ID: <opsdgmqdxpuvpchu@quark> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Sat, 28 Aug 2004 22:48:03 +0200 In-Reply-To: <20040828150437.91976.qmail@web41212.mail.yahoo.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 08:04:37 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> wrote: > However since this is the only issue holding up IDs I don't see why we > can't just compromise on a SHOULD for canonicalizing URIs and move on. I would be okay with that. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 16:57:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12558 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 16:57:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKnX0V099627; Sat, 28 Aug 2004 13:49:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKnXqD099625; Sat, 28 Aug 2004 13:49:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKnXB9099616 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:49:33 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7SKnbuo026391 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:49:37 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOZ60713 (AUTH bob@wyman.us); Sat, 28 Aug 2004 16:49:35 -0400 (EDT) Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "'Atom Syntax'" <atom-syntax@imc.org> Subject: PaceContentSrc (and NewsML similar mechanism) Date: Sat, 28 Aug 2004 16:51:56 -0400 Message-ID: <001201c48d40$dbe50820$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit It may be useful to note that NewsML[1] supports indirect contents in a manner similar to that discussed in PaceContentSrc. NewsML supports the "Href" attribute on "ContentItem" to allow indirect content inclusion: (I think "Href" in NewsML does what "src" is proposed to do in PaceContentSrc.) ... <ContentItem Href="http://example.com/example.html"> <MediaType FormalName="Text"/> <Format FormalName="XHTML"/> </ContentItem> The same content would be in-line if the Href attribute is omitted: ... <ContentItem> <MediaType FormalName="Text"/> <Format FormalName="XHTML"/> <DataContent> <xhtml><p>This is an example.</p></xhtml> </DataContent> </ContentItem> bob wyman [1] http://www.newsml.org/pages/index.php From owner-atom-syntax@mail.imc.org Sat Aug 28 17:06:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12841 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 17:06:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SL02pP002683; Sat, 28 Aug 2004 14:00:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SL02Lg002682; Sat, 28 Aug 2004 14:00:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SL02n3002673 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 14:00:02 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so59574rnb for <atom-syntax@imc.org>; Sat, 28 Aug 2004 14:00:06 -0700 (PDT) Received: by 10.38.1.72 with SMTP id 72mr750632rna; Sat, 28 Aug 2004 14:00:06 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sat, 28 Aug 2004 14:00:06 -0700 (PDT) Message-ID: <1f2ed5cd040828140049dc8b3e@mail.gmail.com> Date: Sat, 28 Aug 2004 23:00:06 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: atom-syntax@imc.org Subject: Purpose of PersonConstruct Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Before going any further, I wonder if it might be possible to clarify the intended purpose of author/contributor elements. Seems to me there are several possible uses, each with slightly different requirements: (first pass) * providing ownership details (i.e. copyright on the content) * providing contact details (i.e. how to get in touch with the person) * providing data for entry processing (e.g. finding entries by the same author) They all boil down to identifying the person entity, but how that's done is another matter. Take the <email> element - probably useful for contact, possibly useful for ownership, probably useful for other processing. Almost certainly useful for spammers. Wouldn't it be better to allow an sha1's version of the address as an alternative? A bit of prior art that may be useful: http://rdfweb.org/mt/foaflog/archives/2003/07/10/12.05.33/ Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Aug 28 17:07:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12913 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 17:07:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKtuOa001448; Sat, 28 Aug 2004 13:55:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SKtugI001447; Sat, 28 Aug 2004 13:55:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SKtuSB001440 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 13:55:56 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail08-en1 [10.13.11.150]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7SKtwAm012740; Sat, 28 Aug 2004 13:55:58 -0700 (PDT) Received: from webmail08 (localhost [127.0.0.1]) by mac.com (Xserve/webmail08/MantshX 4.0) with ESMTP id i7SKtvNI003567; Sat, 28 Aug 2004 13:55:57 -0700 (PDT) Message-ID: <9869595.1093726557362.JavaMail.dtcd@mac.com> Date: Sat, 28 Aug 2004 16:55:57 -0400 From: Graham Parks <dtcd@mac.com> To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Subject: Re: PaceIdConstruct2 created Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, "'Atom Syntax'" <atom-syntax@imc.org> in-reply-to: <opsdglzptduvpchu@quark> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 references: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> <413339e4.199654337@smtp.bjoern.hoehrmann.de> <15068698.1093719331209.JavaMail.dtcd@mac.com> <opsdglzptduvpchu@quark> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SKtuSB001441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Saturday, August 28, 2004, at 04:44PM, Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote: > >On Sat, 28 Aug 2004 14:55:31 -0400, Graham Parks <dtcd@mac.com> wrote: > >> You MUST always use the same ids for your own entries. If you're >> republishing someone else's (say, a feed of search engine results), >> it's only SHOULD. > >Why only SHOULD for republishing? Is it okay to change the title and >content of the entry as well? If not, why can atom:id change, but nothing >else? As I said in the previous reply to you, the system can be much, much more complicated than, say, a script than takes Atom in one end and outputs it on the other. I don't think it's reasonable to assume the id (which is Atom specific) will be preserved if the entry gets changed to other formats on its way through. >Well, that may be the case too. It's up to other parts of the entry (e.g. >a 'modified' date) to give notification about whether the entry has >changed or not. I think atom:id should be silent about that issue. That's what the sentence is there for. I don't think its unreasonable for someone unfamiliar with Atom to think if they have two entries with the same id they only need to process one of them. Think of email, where messages are immutable once sent, adn therefore two emails with the same id can be assumed to be the same. >> I said they "may" be considered versions of one another, not must. I >> don't think there's any need to be more explicit than that. > >But is it necessary to mention at all? We need to say something about what two entries containing the same id means, don't we? Graham From owner-atom-syntax@mail.imc.org Sat Aug 28 17:25:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13944 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 17:25:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SLHEhg008147; Sat, 28 Aug 2004 14:17:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SLHEP1008146; Sat, 28 Aug 2004 14:17:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SLHDEL008137 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 14:17:13 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7SLHGuo000368; Sat, 28 Aug 2004 17:17:16 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOZ67018 (AUTH bob@wyman.us); Sat, 28 Aug 2004 17:17:15 -0400 (EDT) Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "=?iso-8859-1?Q?'Asbj=F8rn_Ulsberg'?=" <asbjorn@tigerstaden.no>, "'Graham Parks'" <dtcd@mac.com>, "'Bjoern Hoehrmann'" <derhoermi@gmx.net> Cc: "'Atom Syntax'" <atom-syntax@imc.org> Subject: RE: PaceIdConstruct2 created Date: Sat, 28 Aug 2004 17:19:36 -0400 Message-ID: <004d01c48d44$b8cafda0$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <opsdglzptduvpchu@quark> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SLHDEL008140 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: >> You MUST always use the same ids for your own entries. If you're >> republishing someone else's (say, a feed of search engine results), >> it's only SHOULD. > Why only SHOULD for republishing? Because a republisher may not have confidence in the correctness of the atom:id. The republisher would give the item a new atom:id in order to prevent any damage that might cause from republishing something that incorrectly duplicated an atom:id used elsewhere. The republisher needs a means (other than simply deleting entries) in order to prevent being a tool in someone's attempt to attack the network. Changing the atom:id can be one tool which, in unusual situations, might make sense to use. > Is it okay to change the title and content of the entry as well? > If not, why can atom:id change, but nothing else? Atom:id is "special" because it is part of the identity mechanism for an entry and uniqueness constraints exist. Title and content have no such uniqueness constraints. bob wyman From owner-atom-syntax@mail.imc.org Sat Aug 28 17:54:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14956 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 17:54:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SLePph012750; Sat, 28 Aug 2004 14:40:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SLePC4012749; Sat, 28 Aug 2004 14:40:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7SLeOC4012730 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 14:40:24 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040828214024.95138.qmail@web41206.mail.yahoo.com> Received: from [24.18.132.80] by web41206.mail.yahoo.com via HTTP; Sat, 28 Aug 2004 14:40:24 PDT Date: Sat, 28 Aug 2004 14:40:24 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: RE: URIs vs Strings To: bob@wyman.us, "'Julian Reschke'" <julian.reschke@gmx.de> Cc: "'Atom Syntax'" <atom-syntax@imc.org> In-Reply-To: <000c01c48d3c$ab5bc990$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Bob Wyman <bob@wyman.us> wrote: > > Julian Reschke wrote: > > This is a good story; and I agree that it can > happen. > Thanks. > > >Consider: > > http://example.com/FooBar > > http://Example.Com/foobar > > http://EXAMPLE.COM/FooBar > > Under canonicalization, there'd still be two > different IDs, although > > all of these would compare equal in a caseless > comparison. > Your example is incomplete. There are 2^4 > semantically-equivalent ways to capitalize "http". > There are 2^10 > semantically-equivalent ways to capitalize > "example.com" and 2^14 > semantically-equivalent ways to capitalize > "http://example.com/". > Canonicalization reduces all these possibilities to > only *one > way*. I see the elimination of (2^14 -1) possible > ways to confuse a > character-by-character comparison as a significant > reduction in the > opportunity to make mistakes. It is not a > "solution"; however, it is a > major step in the right direction. > > Additionally, there are at least 2^6 different ways > to encode > "FooBar" when in a path if one treats path as a URI > component rather > than as a string. Canonicalization only gives us one > correct way to > encode "FooBar" as a string. This reduction in > variety is a good thing > and should result in some improvement in the overall > consistency of Atom > processing. It seems you don't understand how canonicalization works. To spell it out, Julian's point is that the canonicalization of capitalizations does not apply to the path component of HTTP URLs. So http://www.example.com/FOO.txt and http://www.example.com/foo.txt are both in canonical form. Your case of applications generating IDs from database fields where the same ID has different cases will not be helped by canonicalization. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Aug 28 18:36:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17553 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 18:36:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMQAdf016079; Sat, 28 Aug 2004 15:26:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SMQAWd016078; Sat, 28 Aug 2004 15:26:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMQ9G3016064 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:26:10 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so41362rnl for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:26:09 -0700 (PDT) Received: by 10.38.76.76 with SMTP id y76mr320699rna; Sat, 28 Aug 2004 15:26:09 -0700 (PDT) Received: by 10.38.86.38 with HTTP; Sat, 28 Aug 2004 15:26:09 -0700 (PDT) Message-ID: <14be96d3040828152660a60bd4@mail.gmail.com> Date: Sat, 28 Aug 2004 18:26:09 -0400 From: Mark Pilgrim <pilgrim@gmail.com> Reply-To: Mark Pilgrim <pilgrim@gmail.com> To: Bjoern Hoehrmann <derhoermi@gmx.net> Subject: Re: Feeds MUST have alternate links? Cc: atom-syntax@imc.org In-Reply-To: <41354676.202872184@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <87smabifw7.fsf@nwalsh.com> <opsdbsf4uouvpchu@quark> <412DBD74.9040904@intertwingly.net> <opsddo6ujtuvpchu@quark> <14be96d304082706186c6b8a00@mail.gmail.com> <41354676.202872184@smtp.bjoern.hoehrmann.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Sat, 28 Aug 2004 11:06:12 +0200, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > * Mark Pilgrim wrote: > >If you're looking for a syndication format that's even looser and has > >even fewer required elements than RSS, you're in the wrong place. > > It is > > http://www.google.com/search?q=intitle%3A%22untitled+document%22 > http://www.google.com/search?q=intitle%3A%22Welcome+to+Adobe+GoLive%22 > > http://www.google.com/search?q=intitle%3A%22Willkommen+bei+Adobe+GoLive%22 > ... > > pointless to require presence of meta data that is not required for > interoperability, and making meta data up just to satisfy obscure > requirements in a specification actually reduces the value of the > meta data when used properly. That won't help you make your case at all. Channel title has been required in every version of RSS since 1999, and in CDF before that. Are there thousands of "Untitled blog" feeds out there? No. Not all metadata is burdensome. Some is reasonable to require. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Sat Aug 28 18:37:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17592 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 18:37:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMVvH2016411; Sat, 28 Aug 2004 15:31:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SMVvqI016410; Sat, 28 Aug 2004 15:31:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMVusd016396 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:31:56 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7SMW153021956 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:32:01 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3600A9NH9CEV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 28 Aug 2004 16:32:01 -0600 (MDT) Received: from [192.168.1.15] ([216.113.204.14]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I36003LBH9CL2@mail.sun.net> for atom-syntax@imc.org; Sat, 28 Aug 2004 16:32:00 -0600 (MDT) Date: Sat, 28 Aug 2004 15:31:58 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: PaceProtocolDesignTeam In-reply-to: <4130ED3D.6070308@franklinmint.fm> To: Atom Syntax <atom-syntax@imc.org> Message-id: <12F00B58-F942-11D8-BAB9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4130ED3D.6070308@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Aug 28, 2004, at 1:38 PM, Robert Sayre wrote: > The last reading of consensus we had was here: > > http://www.imc.org/atom-syntax/mail-archive/msg07601.html Uh, when I said REST, I actually meant "HTTP transmission of naked Atom markup with no SOAP or any other wrapper". My personal opinion is that this qualifies as REST whether or not you're doing it with GET/POST/PUT/DELETE or just GET/POST, and thus I did not feel that saying "REST" implied four verbs. I have now been painfully educated that there are many who feel that the label REST cannot be applied unless you support PUT and DELETE, so for greater clarity I would now rephrase that statement as: I am pretty sure that there is *overwhelming* community demand for a protocol based on the exchange of Atom documents over HTTP. > there is a *very large* amount of working code to support it. Well, one reason for that is that there are some interesting platforms that can't implement the current proposal because they can't manage four verbs. Note: the WG may decide this is OK, but hasn't yet. > I ask that the co-chairs point to the official record of this WG (this > list), and identify messages that advocate something other than > REST-with-4-verbs as the primary interface for the Atom protocol. I > would also like to know why these messages constitute a body of > evidence sufficient to move consensus from "overwhelming", right past > "rough", to "none." First of all, I note that PaceAtomActionHeader is still in the "to-consider" list. From the List Janne Jalkanen: http://www.imc.org/atom-syntax/mail-archive/msg07614.html http://www.imc.org/atom-syntax/mail-archive/msg07611.html http://www.imc.org/atom-syntax/mail-archive/msg07608.html Paul Hoffman: http://www.imc.org/atom-syntax/mail-archive/msg07575.html Graham Parks: http://www.imc.org/atom-syntax/mail-archive/msg07566.html Sam Ruby: http://www.imc.org/atom-syntax/mail-archive/msg07549.html Me: http://www.imc.org/atom-syntax/mail-archive/msg07474.html Russ Beattie: http://www.imc.org/atom-syntax/mail-archive/msg07316.html Peter Mortier http://www.imc.org/atom-syntax/mail-archive/msg07187.html No, I don't think the WG has consensus on this matter. -Tim From owner-atom-syntax@mail.imc.org Sat Aug 28 18:39:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17717 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 18:39:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMVJ27016367; Sat, 28 Aug 2004 15:31:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SMVJdC016366; Sat, 28 Aug 2004 15:31:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMVIwA016358 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:31:19 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id E177E7C1EE; Sun, 29 Aug 2004 01:21:38 +0200 (CEST) To: bob@wyman.us Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: PaceContentSrc (and NewsML similar mechanism) References: <001201c48d40$dbe50820$6400a8c0@wyman.us> Message-ID: <opsdgrl6uouvpchu@quark> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Sun, 29 Aug 2004 00:33:32 +0200 In-Reply-To: <001201c48d40$dbe50820$6400a8c0@wyman.us> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 16:51:56 -0400, Bob Wyman <bob@wyman.us> wrote: > It may be useful to note that NewsML[1] supports indirect contents > in a manner similar to that discussed in PaceContentSrc. Yes, that's very useful. I support this pace fully. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 18:39:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17761 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 18:39:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMYkTb016606; Sat, 28 Aug 2004 15:34:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SMYkAQ016605; Sat, 28 Aug 2004 15:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMYjhG016598 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:34:45 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7SMYTh8002760; Sat, 28 Aug 2004 18:34:29 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BOZ84376 (AUTH bob@wyman.us); Sat, 28 Aug 2004 18:34:23 -0400 (EDT) Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "'Dare Obasanjo'" <kpako@yahoo.com>, <bob@wyman.us>, "'Julian Reschke'" <julian.reschke@gmx.de> Cc: "'Atom Syntax'" <atom-syntax@imc.org> Subject: RE: URIs vs Strings Date: Sat, 28 Aug 2004 18:36:43 -0400 Message-ID: <000a01c48d4f$7fa2b940$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040828214024.95138.qmail@web41206.mail.yahoo.com> Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > It seems you don't understand how canonicalization works. > To spell it out, Julian's point is that the canonicalization > of capitalizations does not apply to the path component > of HTTP URLs. It seems that you are too quick to jump on potential error... If you read my note you'll see I made *no* reference to capitalization when I mentioned "different ways to encode" the *path* component. My comments on case were restricted to the protocol and domain fields. There are many alternative encodings of the path element that are eliminated by canonicalization. > Your case of applications generating IDs from database fields > where the same ID has different cases will not be helped by canonicalization. Read the example again. Canonicalization will require lowercase for protocol and domain components. Given that these are part of the ID, the probability of case-related errors is reduced -- even though, as I said in my note, it is not eliminated. bob wyman From owner-atom-syntax@mail.imc.org Sat Aug 28 18:46:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18049 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 18:46:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMeVDP017149; Sat, 28 Aug 2004 15:40:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SMeVu5017148; Sat, 28 Aug 2004 15:40:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMeUWP017140 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:40:30 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id AF37C7C1EE; Sun, 29 Aug 2004 01:30:50 +0200 (CEST) Date: Sun, 29 Aug 2004 00:42:46 +0200 To: "Graham Parks" <dtcd@mac.com> Subject: Re: PaceIdConstruct2 created Cc: Atom-Syntax <atom-syntax@imc.org> References: <52E8B64D-F85C-11D8-8440-000A95DC3D90@mac.com> <413339e4.199654337@smtp.bjoern.hoehrmann.de> <15068698.1093719331209.JavaMail.dtcd@mac.com> <opsdglzptduvpchu@quark> <9869595.1093726557362.JavaMail.dtcd@mac.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdgr1kjtuvpchu@quark> In-Reply-To: <9869595.1093726557362.JavaMail.dtcd@mac.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 16:55:57 -0400, Graham Parks <dtcd@mac.com> wrote: > As I said in the previous reply to you, the system can be much, much > more complicated than, say, a script than takes Atom in one end and > outputs it on the other. Uhm, okay. > I don't think it's reasonable to assume the id (which is Atom specific) > will be preserved if the entry gets changed to other formats on its way > through. As far as I can tell, Atom isn't specifying anything else than Atom. What you do with atom:id if you re-publish an Atom entry in e.g. PDF is something out of scope for this specification and WG, afaik. >> Well, that may be the case too. It's up to other parts of the entry >> (e.g. a 'modified' date) to give notification about whether the entry >> has changed or not. I think atom:id should be silent about that issue. > > That's what the sentence is there for. I don't think it should be there. > I don't think its unreasonable for someone unfamiliar with Atom to think > if they have two entries with the same id they only need to process one > of them. If so, the sentence needs to be rewritten. As it reads now, this is very unclear. > We need to say something about what two entries containing the same id > means, don't we? Okay, perhaps we do, but I don't think the text in PaceIdConstruct2 makes this any clearer. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 18:53:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18382 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 18:53:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMluGE018347; Sat, 28 Aug 2004 15:47:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SMluhs018346; Sat, 28 Aug 2004 15:47:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMltKC018337 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:47:55 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 71D0F7C1EE; Sun, 29 Aug 2004 01:38:15 +0200 (CEST) Date: Sun, 29 Aug 2004 00:50:11 +0200 To: "Mark Pilgrim" <pilgrim@gmail.com> Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax <atom-syntax@imc.org> References: <87smabifw7.fsf@nwalsh.com> <opsdbsf4uouvpchu@quark> <412DBD74.9040904@intertwingly.net> <opsddo6ujtuvpchu@quark> <14be96d304082706186c6b8a00@mail.gmail.com> <41354676.202872184@smtp.bjoern.hoehrmann.de> <14be96d3040828152660a60bd4@mail.gmail.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdgsdxsxuvpchu@quark> In-Reply-To: <14be96d3040828152660a60bd4@mail.gmail.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 18:26:09 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote: > That won't help you make your case at all. Channel title has been > required in every version of RSS since 1999, and in CDF before that. How many RSS tools exist that lets you create RSS channel documents with default titles of «Untitled RSS channel», «Welcome to RSS Tool 4!» or something similar? > Not all metadata is burdensome. Some is reasonable to require. <link rel="alternate"> is not purely metadata. It's also a requirement for duplication of data which in case <link> was optional, would not be duplicated. If I want to publish my CD collection (or whatever) as Atom entries in an Atom feed, why do I need to have HTML documents of each CD to which I refer from the Atom entries inside the feed? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 19:04:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18729 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:04:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMwcNX019186; Sat, 28 Aug 2004 15:58:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SMwc0e019185; Sat, 28 Aug 2004 15:58:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail47-s.fg.online.no (mail47-s.fg.online.no [148.122.161.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMwbCR019178 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:58:37 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from mail.online.no (ti132110a080-1917.bb.online.no [80.212.215.125]) by mail47.fg.online.no (8.12.11/8.12.11) with ESMTP id i7SMw5Pf003080; Sun, 29 Aug 2004 00:58:10 +0200 (MEST) To: bob@wyman.us, Atom-syntax <atom-syntax@imc.org> Subject: Re: PaceIdConstruct2 created References: <004d01c48d44$b8cafda0$6400a8c0@wyman.us> Message-ID: <opsdgsq1uo6dxgxk@mail.online.no> Date: Sun, 29 Aug 2004 00:58:03 +0200 From: "Arve Bersvendsen" <arve@virtuelvis.com> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <004d01c48d44$b8cafda0$6400a8c0@wyman.us> User-Agent: Opera M2/7.53 (Win32, build 3850) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 17:19:36 -0400, Bob Wyman <bob@wyman.us> wrote: > Because a republisher may not have confidence in the correctness > of the atom:id. The republisher would give the item a new atom:id in > order to prevent any damage that might cause from republishing something > that incorrectly duplicated an atom:id used elsewhere. If that is the case, why do we even _have_ id's? Drop them entirely. -- Arve Bersvendsen http://www.virtuelvis.com http://www.bersvendsen.com From owner-atom-syntax@mail.imc.org Sat Aug 28 19:05:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18797 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:05:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMwHwL019171; Sat, 28 Aug 2004 15:58:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SMwHps019170; Sat, 28 Aug 2004 15:58:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SMwGii019160 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 15:58:16 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 5BAA17C1EE; Sun, 29 Aug 2004 01:48:36 +0200 (CEST) Date: Sun, 29 Aug 2004 01:00:34 +0200 To: bob@wyman.us Subject: Re: PaceIdConstruct2 created Cc: Atom-Syntax <atom-syntax@imc.org> References: <004d01c48d44$b8cafda0$6400a8c0@wyman.us> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdgsu8rnuvpchu@quark> In-Reply-To: <004d01c48d44$b8cafda0$6400a8c0@wyman.us> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 17:19:36 -0400, Bob Wyman <bob@wyman.us> wrote: > Because a republisher may not have confidence in the correctness > of the atom:id. If re-publishers are allowed to mutate atom:id, doesn't that reduce the value of the construct? I say that atom:id should be immutable for absolutely all publishers on the planet, no matter where the re-published content came from. If a re-publisher don't «trust» (how do you define trust in this context?) the content (be it atom:id or whatever), it's better not to re-publish the entry than to mutate parts of it -- especially atom:id, since that should be immutable. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 19:06:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18848 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:06:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SN1coK019506; Sat, 28 Aug 2004 16:01:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SN1cgK019505; Sat, 28 Aug 2004 16:01:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SN1ci9019496 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:01:38 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 33354 invoked by uid 17064); 28 Aug 2004 23:01:41 -0000 Received: from unknown (HELO [192.168.0.2]) ([81.249.183.38]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <bobwyman@pubsub.com>; 28 Aug 2004 23:01:41 -0000 In-Reply-To: <000501c48d33$b155b850$6400a8c0@wyman.us> References: <000501c48d33$b155b850$6400a8c0@wyman.us> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <35116FAE-F946-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "<bobwyman@pubsub.com> <bobwyman@pubsub.com>" <bobwyman@pubsub.com>, Ken MacLeod <ken@bitsko.slc.ut.us> From: Henry Story <henry.story@bblfish.net> Subject: It's the entry, Stupid! ;-) [1] Date: Sun, 29 Aug 2004 01:01:34 +0200 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 28 Aug 2004, at 21:17, Bob Wyman wrote: > Henry Story wrote: >> First of all notice that if someone is maliciously changing >> id's they could also maliciously change the source-feed. > It's not "changing" ids, it's "copying" or "spoofing" ids that's > the problem.. That still sounds malicious. If it is malicious then it is in the end a matter for the courts. [Snip very interesting description of pubsub verification mechanism... I'd like to get back to this after clarifying the following point.] >> I think there are many other ways to do this also. > I would appreciate it if you could describe at least a few more > of the "many other ways" that you know of. > > You propose: >> a feed is just a pointer to a bunch of entries... >> Each entry is a resource (REST), where we can >> find all the information about the entry itself. > This would work, technically, however, I don't think it is > likely to become accepted practice since it would result in quite a few > additional network roundtrips. I think on the contrary that the RESTful way I propose is going to be much more efficient network wise. I was convinced of this by Ken MacLeod during a long conversation on Atom irc a couple of months ago. He helped me rebuild my model quite dramatically. Here are some things to keep in mind. (1). With HTTP 1.1 Persistent connections only one tcp connection is needed to get all the data from a feed. If the client does not find some of the entries in its database it can request them in the same tcp connection. As an example Imagine this is part of your feed file in N3 notation: <> a :Feed ; :dynamic <> ; :entry <entry.2004-08-13-1047.n3> , <entry.2004-08-13-1445.n3> , <entry.2004-08-13-1752.n3> , <entry.2004-08-13-1632.n3>. <entry.2004-08-13-1047.n3> :entry-version <tag:bblfish.net/20040813/1047/blog1#version2> ; :id <tag:bblfish.net/20040813/1047/blog1> . The client fetches this feed and notices that entry.2004-08-13-1047.n3 is at version2. Having parsed this feed file the client can fetch the changed entry without having to open a new tcp connection. (2). The thing that gets polled often is the feed. So we want small feed files to minimize the number of packets sent over the internet. No need to send the whole entry text. The client will most likely already have those from the previous time he polled the feed. This is clearly achieved in the example above. All we really need to send in the feed is the entry resources and their id and version ids. (Additional information, such as the feed title can of course also be sent, but I just want to limit myself to what is necessary at first). (3) as explained in my previous e-mail this also helps you solve your problem of checking the id of an entry. Just download the entry itself. In most cases this should be at the location specified by the resource. (4) "It's the entry, Stupid!" [1] Entries should be first class citizens in atom. If they have http retrievable urls then they can also be edited and updated at those urls using PUT, POST and DELETE. > The feed has the nice property of > gathering entries together so that they can be retrieved with an > economy > of network operations. Admittedly, what I'm proposing in my "method" is > that services like PubSub actually do additional work to verify > entries. > However, this work is optional and is not required of *all* processors > of feeds -- as would be the case in your proposal. I think if you look at packets sent over the network you will find that the restful method I propose is in fact much better for the network, it allows caches on the internet to work properly, it reduces information transmission to what is necessary,... > What you're proposing is a good "model" for how the system > should work, however, I'm afraid that a direct implementation of the > model isn't the right thing to do. The "extra-model" operation of > copying entries into the feed, even if they exist as resources on the > web, is necessary as a practicle means of making the reading of > collections of entries more convenient and less complex for the average > client developer. I am going to be developing a client myself to do this, and I really don't think that this is going to be much extra work. Also I think one should try not to confuse architecture and implementation. If Tim Berner's lee had taken this into account, he would have tried to incorporate images directly into the html too, and we would not separate the styles sheets from the html, ... I think this is just basic to the operation of the web. > Or, have I not properly understood what you propose? > > bob wyman > [1] title take from http://www.imc.org/atom-syntax/mail-archive/msg04596.html From owner-atom-syntax@mail.imc.org Sat Aug 28 19:08:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18923 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:08:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SN2OBn019593; Sat, 28 Aug 2004 16:02:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SN2OrN019592; Sat, 28 Aug 2004 16:02:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SN2NKv019585 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:02:23 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7SN2Sil013649 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 17:02:28 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I36008IWIO4GB@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 28 Aug 2004 17:02:28 -0600 (MDT) Received: from [192.168.1.15] ([216.113.204.14]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I3600BK9IO0CF@mail.sun.net> for atom-syntax@imc.org; Sat, 28 Aug 2004 17:02:25 -0600 (MDT) Date: Sat, 28 Aug 2004 16:02:20 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Feeds MUST have alternate links? In-reply-to: <opsdgsdxsxuvpchu@quark> To: Atom-Syntax <atom-syntax@imc.org> Message-id: <50FBF734-F946-11D8-BAB9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <87smabifw7.fsf@nwalsh.com> <opsdbsf4uouvpchu@quark> <412DBD74.9040904@intertwingly.net> <opsddo6ujtuvpchu@quark> <14be96d304082706186c6b8a00@mail.gmail.com> <41354676.202872184@smtp.bjoern.hoehrmann.de> <14be96d3040828152660a60bd4@mail.gmail.com> <opsdgsdxsxuvpchu@quark> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SN2NKv019586 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit I think Asbjørn and others have presented plausible cases for feeds you might create where there's not an instantly-obvious choice for the "alternate" link. Still, I think we should require them; at least you can point to an HTML page somewhere with a human-readable description saying "This feed describes variations in the readings from the potentiometer X328951 in rack 211-B" or something. Among other things, if you ran across such a feed in the wild and didn't know what it was about, having a standard link to follow to find out would be nice. And the cost is low. -Tim From owner-atom-syntax@mail.imc.org Sat Aug 28 19:11:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19037 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:11:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SN4TDL019745; Sat, 28 Aug 2004 16:04:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SN4TYY019744; Sat, 28 Aug 2004 16:04:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SN4T7L019736 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:04:29 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1CFK-0005Wv-LC; Sat, 28 Aug 2004 23:04:30 +0000 Message-ID: <41310F81.9060603@franklinmint.fm> Date: Sat, 28 Aug 2004 19:04:33 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray <Tim.Bray@Sun.COM> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceProtocolDesignTeam References: <4130ED3D.6070308@franklinmint.fm> <12F00B58-F942-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <12F00B58-F942-11D8-BAB9-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 28, 2004, at 1:38 PM, Robert Sayre wrote: > >> The last reading of consensus we had was here: >> >> http://www.imc.org/atom-syntax/mail-archive/msg07601.html > > > Uh, when I said REST, I actually meant "HTTP transmission of naked Atom > markup with no SOAP or any other wrapper". I apologize for mischaracterizing your views. > My personal opinion is that > this qualifies as REST whether or not you're doing it with > GET/POST/PUT/DELETE or just GET/POST, and thus I did not feel that > saying "REST" implied four verbs. > I am pretty sure that there is *overwhelming* community demand for a > protocol based on the exchange of Atom documents over HTTP. > >> there is a *very large* amount of working code to support it. > > > Well, one reason for that is that there are some interesting platforms > that can't implement the current proposal because they can't manage four > verbs. This is not true. Name one platform that can't implement the Atom Protocol as of draft-gregorio-09 (counting the SHOULD-level SOAP fallback). > Note: the WG may decide this is OK, but hasn't yet. > >> I ask that the co-chairs point to the official record of this WG (this >> list), and identify messages that advocate something other than >> REST-with-4-verbs as the primary interface for the Atom protocol. I >> would also like to know why these messages constitute a body of >> evidence sufficient to move consensus from "overwhelming", right past >> "rough", to "none." > > > First of all, I note that PaceAtomActionHeader is still in the > "to-consider" list. > I note that PaceAtomActionHeader positions itself as a fallback mechanism. Though I recognize the authority of the co-chairs, I see no rationale or support for positioning either SOAP or PaceAtomActionHeader as the primary mechanism for the protocol. There is a disagreement about the headers/verbs/http issue, but there is next to zero support for SOAP as the primary. This should be removed from consideration in the Pace. As for the email list, I feel the co-chairs have mostly cited arguments around a "fallback" mechanism. Which one of them calls for PUT/DELETE to be abandoned? I'll also note that Peter Mortier's email seems to advocate my own POV. Binary POST, SOAP to edit (PUT/DELETE): "I would like to see a primary mechanism, using POST to upload binary objects to an Atom enabled server. This is the most common use case for a mobile user. When subsequent editing/replacing of an existing binary object requires a SOAP envelope, base64 encoding and gzipping it all on MIDP then I could possibly be OK with that too, since like you say this is indeed an infrequent action." Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 19:20:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19234 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:20:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNBXtF020337; Sat, 28 Aug 2004 16:11:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNBXc4020336; Sat, 28 Aug 2004 16:11:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNBX9A020329 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:11:33 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc13) with SMTP id <2004082823113301500lunive>; Sat, 28 Aug 2004 23:11:33 +0000 Date: Sat, 28 Aug 2004 17:11:32 -0600 Subject: Re: PaceIdConstruct2 created Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org In-Reply-To: <opsdgsu8rnuvpchu@quark> Message-Id: <997E5F92-F947-11D8-91ED-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SNBX9A020331 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Saturday, August 28, 2004, at 05:00 PM, Asbjørn Ulsberg wrote: >> Because a republisher may not have confidence in the correctness >> of the atom:id. > > If re-publishers are allowed to mutate atom:id, doesn't that reduce > the value of the construct? I say that atom:id should be immutable for > absolutely all publishers on the planet, no matter where the > re-published content came from. > > If a re-publisher don't «trust» (how do you define trust in this > context?) the content (be it atom:id or whatever), it's better not to > re-publish the entry than to mutate parts of it -- especially atom:id, > since that should be immutable. > Let's say I'm taking Atom entries and storing parts of each entry in a database, but I'm not storing IDs because I don't plan on re-publishing later. But later, I decide to go ahead and republish. Or someone else who has access to the database decides to publish and Atom feed based on it. Or the data gets published as an RSS feed which is converted to a ... which is converted to a ... which is converted to an Atom feed. There are a million ways the original ID could get lost. In that case, the re-publisher should generate a new ID, and use that ID consistently when re-publishing the data. Re-publishers SHOULD keep the ID the same--we are encouraging them strongly to track the ID. But it simply won't happen in all cases. From owner-atom-syntax@mail.imc.org Sat Aug 28 19:25:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19331 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:25:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNJTsU020823; Sat, 28 Aug 2004 16:19:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNJTCW020822; Sat, 28 Aug 2004 16:19:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNJSGc020807 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:19:29 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id DE62F7C1EE; Sun, 29 Aug 2004 02:09:48 +0200 (CEST) Date: Sun, 29 Aug 2004 01:21:52 +0200 To: "Tim Bray" <Tim.Bray@sun.com> Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax <atom-syntax@imc.org> References: <87smabifw7.fsf@nwalsh.com> <opsdbsf4uouvpchu@quark> <412DBD74.9040904@intertwingly.net> <opsddo6ujtuvpchu@quark> <14be96d304082706186c6b8a00@mail.gmail.com> <41354676.202872184@smtp.bjoern.hoehrmann.de> <14be96d3040828152660a60bd4@mail.gmail.com> <opsdgsdxsxuvpchu@quark> <50FBF734-F946-11D8-BAB9-000A95A51C9E@sun.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdgtuqnquvpchu@quark> In-Reply-To: <50FBF734-F946-11D8-BAB9-000A95A51C9E@sun.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 16:02:20 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote: > I think Asbjørn and others have presented plausible cases for feeds you > might create where there's not an instantly-obvious choice for the > "alternate" link. Still, I think we should require them; at least you > can point to an HTML page somewhere with a human-readable description > saying "This feed describes variations in the readings from the > potentiometer X328951 in rack 211-B" or something. What about required «alternate» links from entries? And why do one need this alternate link? Can't it at least be «about»? > Among other things, if you ran across such a feed in the wild and > didn't know what it was about, having a standard link to follow to find > out would be nice. And the cost is low. For the feed, the cost is acceptable. For the entries, it's imho not. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 19:27:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19420 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:27:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNL5V9020914; Sat, 28 Aug 2004 16:21:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNL5uH020913; Sat, 28 Aug 2004 16:21:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNL50q020907 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:21:05 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail01-en1 [10.13.11.143]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7SNLAOo028327; Sat, 28 Aug 2004 16:21:10 -0700 (PDT) Received: from webmail01 (localhost [127.0.0.1]) by mac.com (Xserve/webmail01/MantshX 4.0) with ESMTP id i7SNL9hb016949; Sat, 28 Aug 2004 16:21:09 -0700 (PDT) Message-ID: <12957596.1093735269609.JavaMail.dtcd@mac.com> Date: Sat, 28 Aug 2004 19:21:09 -0400 From: Graham Parks <dtcd@mac.com> To: bob@wyman.us Subject: RE: URIs vs Strings Cc: "'Atom Syntax'" <atom-syntax@imc.org> in-reply-to: <000a01c48d4f$7fa2b940$6400a8c0@wyman.us> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <000a01c48d4f$7fa2b940$6400a8c0@wyman.us> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Saturday, August 28, 2004, at 06:39PM, Bob Wyman <bob@wyman.us> wrote: > Read the example again. Canonicalization will require lowercase > for protocol and domain components. Given that these are part of the ID, > the probability of case-related errors is reduced -- even though, as I > said in my note, it is not eliminated. So, am I right in thinking that the benefits of c14n amount to: i) Protection from millions of times each day that someone rewrites id generation code but chooses different capitalization for the scheme or domain name, but somehow remembers not to make any other changes. ii) Gateways that either don't exist, don't currently pass ids through at all, or don't mangle ids, but it's assumed will inevitably all start canonicalizing for the sake of it, because "search engines canonicalize all the time", in a completely different context. iii) Implementors that don't read the spec and use C# or Java URI comparison classes, and who come across feeds where one entry has id "http://www.example.com/", and another has "HTTP://www.example.com/", and won't conflate the entries. Are you shitting me? Graham From owner-atom-syntax@mail.imc.org Sat Aug 28 19:30:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19554 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:30:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNKsSf020894; Sat, 28 Aug 2004 16:20:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNKsOE020893; Sat, 28 Aug 2004 16:20:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNKrB0020887 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:20:54 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1CVE-0007cp-13 for atom-syntax@imc.org; Sat, 28 Aug 2004 23:20:56 +0000 Message-ID: <4131135A.70805@franklinmint.fm> Date: Sat, 28 Aug 2004 19:20:58 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax <atom-syntax@imc.org> Subject: PaceProtocolDesignTeam2 revised Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit I've revised the Pace, removing any assertions about consensus. Note that debate on PUT/DELETE, etc. would be off-topic for the proposed design team list (but not atom-syntax). Robert Sayre Abstract ------------------------ Create a new, open design team that focuses strictly on the Atom protocol. Status ------------------------ Open Supporters ------------------------ Robert Sayre Sam Ruby Rationale ------------------------ There are folks who are interested in helping with the Atom publishing protocol haven't been following the Atom mailing list due to the volume of messages and the dearth of protocol discussion. Creating a design team for just the protocol gives a more focused forum for those folks while letting the main mailing list spend more time on the seemingly-difficult parts of the format document. Though the capabilities required are accurately listed in the charter, there has been a dearth of debate on many of the goals listed there. Six Apart is moving ahead with work in the protocol area (http://sixapart.com/developers/atom/typepad/), but perhaps not in a manner identical to what the WG will choose. This group will focus on issues such as introspection, "categories", URIs that require extension elements, management of templates and users, and recommendations and requirements for implementations that wish to extend the Atom Publishing Protocol. Proposal ------------------------ Create a "design team" for completing the list of all the actions that need to be in the Atom protocol. Note that there is no formal definition of design teams in the IETF, and they can be created under rules chosen by the WG chairs. For this design team, we propose a mailing list open to anyone, whose only restriction is that the only initial topic for discussion is the needed actions for the Atom protocol, with the exception of debating the use of PUT and DELETE. It is assumed that the atom-syntax list will propose an equally capable mechanism if an alternative is required. The protocol design team will propose to the WG ways of closing all open issues in the Atom protocol document. The document editors will revise the protocol document based on what they hear from the WG. Notes ------------------------ This group will work with the assumption that the primary interface to the Atom Publishing Protocol is REST with 4 verbs. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 19:32:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19634 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:32:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNQAuD021072; Sat, 28 Aug 2004 16:26:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNQAXi021071; Sat, 28 Aug 2004 16:26:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNQ9oU021063 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:26:09 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id B18967C1F9; Sun, 29 Aug 2004 02:16:29 +0200 (CEST) To: "Danny Ayers" <danny.ayers@gmail.com> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: Purpose of PersonConstruct References: <1f2ed5cd040828140049dc8b3e@mail.gmail.com> Message-ID: <opsdgt5vvzuvpchu@quark> Date: Sun, 29 Aug 2004 01:28:33 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <1f2ed5cd040828140049dc8b3e@mail.gmail.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 23:00:06 +0200, Danny Ayers <danny.ayers@gmail.com> wrote: > They all boil down to identifying the person entity, but how that's > done is another matter. [...] Wouldn't it be better to allow an > sha1's version of the address as an alternative? I've thought about this for a while, and many others have probably too, but since I know as much as virtually nothing about FOAF, I have no idea how to attack the problem. Can't you, or anyone else with FOAF-knowledge, write up a pace, blog entry or whatever, that explains how FOAF can be used to identify authors in Atom? It would be very useful. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 19:34:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19691 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:34:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNSW2o021211; Sat, 28 Aug 2004 16:28:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNSWD5021210; Sat, 28 Aug 2004 16:28:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNSVkY021204 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:28:32 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so62302rnb for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:28:32 -0700 (PDT) Received: by 10.38.1.72 with SMTP id 72mr791093rna; Sat, 28 Aug 2004 16:28:32 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sat, 28 Aug 2004 16:28:32 -0700 (PDT) Message-ID: <1f2ed5cd04082816286531c280@mail.gmail.com> Date: Sun, 29 Aug 2004 01:28:32 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> Subject: Re: URIs vs Strings Cc: Dare Obasanjo <kpako@yahoo.com>, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <opsdgmqdxpuvpchu@quark> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <20040828150437.91976.qmail@web41212.mail.yahoo.com> <opsdgmqdxpuvpchu@quark> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SNSWkY021205 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 22:48:03 +0200, Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote: > > On Sat, 28 Aug 2004 08:04:37 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> > wrote: > > > However since this is the only issue holding up IDs I don't see why we > > can't just compromise on a SHOULD for canonicalizing URIs and move on. > > I would be okay with that. Me too. Nor can I think of any other publication-oriented system which demands URI canonicalization, so no matter how desirable it seems, it's pretty well untested, and SHOULD may be the cautious choice. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Aug 28 19:39:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19753 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:38:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNVIip021330; Sat, 28 Aug 2004 16:31:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNVIGP021329; Sat, 28 Aug 2004 16:31:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNVIlh021323 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:31:18 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail01-en1 [10.13.11.143]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7SNVOAm007348; Sat, 28 Aug 2004 16:31:24 -0700 (PDT) Received: from webmail01 (localhost [127.0.0.1]) by mac.com (Xserve/webmail01/MantshX 4.0) with ESMTP id i7SNVNhb017122; Sat, 28 Aug 2004 16:31:23 -0700 (PDT) Message-ID: <1123422.1093735883140.JavaMail.dtcd@mac.com> Date: Sat, 28 Aug 2004 19:31:23 -0400 From: Graham Parks <dtcd@mac.com> To: Sam Ruby <rubys@intertwingly.net> Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax <atom-syntax@imc.org> in-reply-to: <412F804A.6000405@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Friday, August 27, 2004, at 02:52PM, Sam Ruby <rubys@intertwingly.net> wrote: >I direct everybody interested in pursuing this to read the first >sentence of the charter and try to come up with meaningful examples of >web resources for which Universal Resource Identifiers can not be provided. Atom entries. "Web resource" is used several times in the charter to refer to Atom entries. Yet the charter says the designated format for Atom entries to be published in is "representing multiple resources in a single document". Only the docuemtn will have a resolvable URI - the resources won't. Addtionally, good luck using the word MUST to describe this requirement: "In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm" >The reason for this is quite simple: we are having a hard enough time >staying on track for things that are in scope without dealing with >explorations of new possible applications. It might help if the secretary and chairs spent less time telling everyone to shut up, and more time trying to recognize or encourage consensus. Graham From owner-atom-syntax@mail.imc.org Sat Aug 28 19:44:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19918 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:44:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNboOs021672; Sat, 28 Aug 2004 16:37:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNbobN021671; Sat, 28 Aug 2004 16:37:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail43-s.fg.online.no (mail43-s.fg.online.no [148.122.161.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNbnDt021663 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:37:49 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from mail.online.no (ti132110a080-1917.bb.online.no [80.212.215.125]) by mail43.fg.online.no (8.12.11/8.12.11) with ESMTP id i7SNbfED004818; Sun, 29 Aug 2004 01:37:44 +0200 (CEST) Date: Sun, 29 Aug 2004 01:37:38 +0200 To: "Toru Marumoto" <torumyax@yahoo.co.jp>, Atom-syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> From: "Arve Bersvendsen" <arve@virtuelvis.com> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdguk0g86dxgxk@mail.online.no> In-Reply-To: <CBC48C5EB9FAD9torumyax@yahoo.co.jp> User-Agent: Opera M2/7.53 (Win32, build 3850) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 02:53:14 +0900, Toru Marumoto <torumyax@yahoo.co.jp> wrote: > You are supporsed to click on the title to see the acutural content on > the web in a web browser. Looking at stats from my personal blogs, I tend to disagree. I have more visitors to the full-content feeds than to all other feeds combined. I am +1 on making <link rel="alternate" /> a MAY instead of a MUST. Anyhow: Could anyone say how much sense a <link rel="alternate" /> would make in the case of: * Windows Event Logs via Atom? <URL:http://www.rassoc.com/gregr/weblog/archive.aspx?post=570> * E-mail via Atom, <URL:http://www.iupload.com/product/mailbyrss.asp> -- Arve Bersvendsen http://www.virtuelvis.com http://www.bersvendsen.com From owner-atom-syntax@mail.imc.org Sat Aug 28 19:45:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19985 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:45:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNd3n3021738; Sat, 28 Aug 2004 16:39:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNd35s021737; Sat, 28 Aug 2004 16:39:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNd3Wr021728 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:39:03 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc12) with SMTP id <2004082823390301200c1s9je>; Sat, 28 Aug 2004 23:39:03 +0000 Date: Sat, 28 Aug 2004 17:39:01 -0600 Subject: Re: It's the entry, Stupid! ;-) [1] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <35116FAE-F946-11D8-ADE0-000A95D9FA7A@bblfish.net> Message-Id: <70D258AC-F94B-11D8-91ED-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Saturday, August 28, 2004, at 05:01 PM, Henry Story wrote: >>> a feed is just a pointer to a bunch of entries... >>> Each entry is a resource (REST), where we can >>> find all the information about the entry itself. >> This would work, technically, however, I don't think it is >> likely to become accepted practice since it would result in quite a >> few >> additional network roundtrips. > > I think on the contrary that the RESTful way I propose is going to be > much more efficient network wise. I was convinced of this by Ken > MacLeod during a long conversation on Atom irc a couple of months ago. > He helped me rebuild my model quite dramatically. Here are some things > to keep in mind. > > (1). With HTTP 1.1 Persistent connections only one tcp connection is > needed to get all the data from a feed. If the client does not find > some of the entries in its database it can request them in the same > tcp connection. > ...assuming that all the data is on the same server. Rather than building pointer-only feeds into the format, thus requiring clients that don't support the API to be able to handle them, it might be better to do such things via the API. For example, we might define methods to query for a list of the most recent IDs (which could be checked against your cache to see which are new), and a method to query for a set of entries (by ID), which would be returned in the standard feed format. From owner-atom-syntax@mail.imc.org Sat Aug 28 19:48:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20122 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:48:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNhARf021934; Sat, 28 Aug 2004 16:43:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNhApq021933; Sat, 28 Aug 2004 16:43:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNhA4K021927 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:43:10 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1Cqk-0001nk-Sl; Sat, 28 Aug 2004 23:43:10 +0000 Message-ID: <41311891.30609@franklinmint.fm> Date: Sat, 28 Aug 2004 19:43:13 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks <dtcd@mac.com> CC: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> <1123422.1093735883140.JavaMail.dtcd@mac.com> In-Reply-To: <1123422.1093735883140.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Graham Parks wrote: > On Friday, August 27, 2004, at 02:52PM, Sam Ruby <rubys@intertwingly.net> wrote: > > >>I direct everybody interested in pursuing this to read the first >>sentence of the charter and try to come up with meaningful examples of >>web resources for which Universal Resource Identifiers can not be provided. > > > Atom entries. "Web resource" is used several times in the charter to refer to Atom entries. Yet the charter says the designated format for Atom entries to be published in is "representing multiple resources in a single document". Only the docuemtn will have a resolvable URI - the resources won't. > The current draft no longer states or implies that the alternate link must be a web page or retrievable over http. If the entry doesn't have an alternate representation that can be identified by a URI, it isn't syndication--it's messaging. We're not here to deal with messaging. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 19:59:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20454 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 19:59:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNsZ5B022581; Sat, 28 Aug 2004 16:54:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNsZeO022580; Sat, 28 Aug 2004 16:54:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNsZJu022570 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:54:35 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so62709rnb for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:54:35 -0700 (PDT) Received: by 10.38.1.72 with SMTP id 72mr797204rna; Sat, 28 Aug 2004 16:54:35 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sat, 28 Aug 2004 16:54:35 -0700 (PDT) Message-ID: <1f2ed5cd04082816544eb0a9fe@mail.gmail.com> Date: Sun, 29 Aug 2004 01:54:35 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> Subject: Re: Purpose of PersonConstruct Cc: Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <opsdgt5vvzuvpchu@quark> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <1f2ed5cd040828140049dc8b3e@mail.gmail.com> <opsdgt5vvzuvpchu@quark> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SNsZJu022575 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sun, 29 Aug 2004 01:28:33 +0200, Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote: > On Sat, 28 Aug 2004 23:00:06 +0200, Danny Ayers <danny.ayers@gmail.com> > wrote: > > > They all boil down to identifying the person entity, but how that's > > done is another matter. [...] Wouldn't it be better to allow an > > sha1's version of the address as an alternative? > > I've thought about this for a while, and many others have probably too, > but since I know as much as virtually nothing about FOAF, I have no idea > how to attack the problem. > > Can't you, or anyone else with FOAF-knowledge, write up a pace, blog entry > or whatever, that explains how FOAF can be used to identify authors in > Atom? It would be very useful. Bit late at night here, but one or two maybe relevant points. FOAF acknowledges that it's hard to identify a person using a single piece of data, and a URI for various reasons is inappropriate. So provision is made to allow multiple properties, some of which are 'inverse functional properties' (IFPs) which can be used as a kind of key field, so a mailbox property will only refer to one person, similarly a homepage property and IM id property. Atom is close in using multiple fields: name, uri and email. (Noting previous comment re. not using live email addresses in harvestable docs - the sha1 hash of the address will only refer to one person, it's another IFP). Another point is that I think there's a very simple pragmatic way of using FOAF with the current Atom format spec. A relatively recent addition is the PersonalProfileDocument (PPD) class, which can be used (within the RDF) to say this FOAF doc is about this person. That appears to mesh well with the <uri> element within Atom's Person construct: "...conveys a URI associated with the person." - just give it the URI of a PPD. One final thing, there's a slight structural mismatch between the way FOAF does its thing-person associations and the way Atom does them. By example - FOAF is roughly: <entry><maker><Person><name>Jane</name></Person></maker><entry> Atom is roughly: <entry><author><name>Jane</name></author></entry> - the person and relationship have been compressed into a single term. This may make it difficult to use (namespaced) FOAF terms directly inside Atom. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Aug 28 20:00:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20496 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 20:00:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNog6V022298; Sat, 28 Aug 2004 16:50:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNogno022297; Sat, 28 Aug 2004 16:50:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNogBE022291 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:50:42 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail01-en1 [10.13.11.143]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7SNokkN016169; Sat, 28 Aug 2004 16:50:46 -0700 (PDT) Received: from webmail01 (localhost [127.0.0.1]) by mac.com (Xserve/webmail01/MantshX 4.0) with ESMTP id i7SNojhb017450; Sat, 28 Aug 2004 16:50:46 -0700 (PDT) Message-ID: <13157435.1093737045425.JavaMail.dtcd@mac.com> Date: Sat, 28 Aug 2004 19:50:45 -0400 From: Graham Parks <dtcd@mac.com> To: Robert Sayre <mint@franklinmint.fm> Subject: Re: Feeds MUST have alternate links? Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org> in-reply-to: <41311891.30609@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> <1123422.1093735883140.JavaMail.dtcd@mac.com> <41311891.30609@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Saturday, August 28, 2004, at 07:43PM, Robert Sayre <mint@franklinmint.fm> wrote: >The current draft no longer states or implies that the alternate link >must be a web page or retrievable over http. If the entry doesn't have >an alternate representation that can be identified by a URI, it isn't >syndication--it's messaging. We're not here to deal with messaging. http://dictionary.reference.com/search?q=syndication says: "To sell (a comic strip or column, for example) through a syndicate for simultaneous publication in newspapers or periodicals." Where does it say I have to publish a copy too? Meanwhile, our beloved secretary is busy discussing using Atom for messaging on the other thread. Never mind. Graham From owner-atom-syntax@mail.imc.org Sat Aug 28 20:05:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20619 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 20:05:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNx4Oh022775; Sat, 28 Aug 2004 16:59:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SNx4cD022774; Sat, 28 Aug 2004 16:59:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SNx2la022768 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 16:59:04 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1D67-0003mD-RR; Sat, 28 Aug 2004 23:59:03 +0000 Message-ID: <41311C4A.3070808@franklinmint.fm> Date: Sat, 28 Aug 2004 19:59:06 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks <dtcd@mac.com> CC: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> <1123422.1093735883140.JavaMail.dtcd@mac.com> <41311891.30609@franklinmint.fm> <13157435.1093737045425.JavaMail.dtcd@mac.com> In-Reply-To: <13157435.1093737045425.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Graham Parks wrote: > On Saturday, August 28, 2004, at 07:43PM, Robert Sayre <mint@franklinmint.fm> wrote: > > >>The current draft no longer states or implies that the alternate link >>must be a web page or retrievable over http. If the entry doesn't have >>an alternate representation that can be identified by a URI, it isn't >>syndication--it's messaging. We're not here to deal with messaging. > > > http://dictionary.reference.com/search?q=syndication says: > "To sell (a comic strip or column, for example) through a syndicate for simultaneous publication in newspapers or periodicals." > LOL. Where does that definition say anything about what we're doing here? Yes, we have a new sense of the word "syndication" here. Cite prior art in RSS/RDF/CDF and I'll acknowledge your point, and it won't violate the charter either. Please refrain from ad hominem attacks on this list. It makes it hard for people who agree with you to support your point of view. If you have issues with the way the WG is being run, your recourse is to contact the Applications Area Directors. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 20:23:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21260 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 20:23:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T0H8Bp023502; Sat, 28 Aug 2004 17:17:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T0H8H4023501; Sat, 28 Aug 2004 17:17:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T0H8at023490 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 17:17:08 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc12) with SMTP id <20040829001708014008nktee>; Sun, 29 Aug 2004 00:17:09 +0000 Date: Sat, 28 Aug 2004 18:17:07 -0600 Subject: Re: Feeds MUST have alternate links? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <41311891.30609@franklinmint.fm> Message-Id: <C311BE88-F950-11D8-91ED-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Saturday, August 28, 2004, at 05:43 PM, Robert Sayre wrote: > If the entry doesn't have an alternate representation that can be > identified by a URI, it isn't syndication--it's messaging. We're not > here to deal with messaging. > That depends on how you define syndication. From the charter: "The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document." That doesn't say anything about each of those resources existing both within and without the feed. The preceding sentence: "Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content." What is a "web resource"? Is the web HTTP? HTML? HTTP+HTML? Was this sentence intended to preclude consideration of other "internet resources"? In particular, are the Atom feed itself or its entries "web resources"? An entry is certainly "similar content" to a weblog entry, and a feed to a weblog. Is the required link merely a ritual cat that we're going out of our way to tie up, or is there a cat out there that's going to do something bad if we don't tie it up? It just seems to me that we're making a requirement which limits Atom's flexibility without providing any benefit. Unless processing feeds without links would be non-trivially difficult, why require links? From owner-atom-syntax@mail.imc.org Sat Aug 28 20:32:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21585 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 20:32:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T0OLx0023905; Sat, 28 Aug 2004 17:24:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T0OLgd023904; Sat, 28 Aug 2004 17:24:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T0OK7i023898 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 17:24:20 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 25BF77C1F9; Sun, 29 Aug 2004 03:14:40 +0200 (CEST) Date: Sun, 29 Aug 2004 02:26:56 +0200 To: "Robert Sayre" <mint@franklinmint.fm> Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax <atom-syntax@imc.org> References: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> <1123422.1093735883140.JavaMail.dtcd@mac.com> <41311891.30609@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdgwu6gsuvpchu@quark> In-Reply-To: <41311891.30609@franklinmint.fm> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 19:43:13 -0400, Robert Sayre <mint@franklinmint.fm> wrote: > If the entry doesn't have an alternate representation that can be > identified by a URI, it isn't syndication--it's messaging. Where did you read that definition? Why do you need an external copy, in an alternate format, for each entry to be able to call it «syndication»? Isn't the point of syndication to (re-) publish a news item in several places (at once)? How can this in any way conflate with messaging, and anyhoo: Why can't Atom be used for messagin? > We're not here to deal with messaging. If you're so certain that entries without alternate, external representations can't be syndication, why can't Atom deal with messaging too? I'm in the opinion that syndication is something else, but nonetheless, I think Atom should cater for this exact need. Machine-to-machine communication should be possible to do, and in such cases, absolutely all alternate representations is nothing but extra work with absolutely no gain for anyone. Most of the feeds that don't need or can't provide <link> for entries (or feeds, perhaps) won't be advertised as regular Atom subscription feeds. E.g., they won't say «Click here to subscribe to Xyz!». Hence, they won't get users into huge problems where they suddenly have feeds that don't refer to HTML representations of the entries. Either way, that shouldn't be a big problem for anyone. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Aug 28 20:53:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22288 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 20:53:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T0hpFB025290; Sat, 28 Aug 2004 17:43:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T0hp6Z025289; Sat, 28 Aug 2004 17:43:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T0hpMS025283 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 17:43:51 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1DnY-00011a-R4; Sun, 29 Aug 2004 00:43:56 +0000 Message-ID: <413126CC.5020904@franklinmint.fm> Date: Sat, 28 Aug 2004 20:43:56 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy <antone@geckotribe.com> CC: atom-syntax@imc.org Subject: Re: Feeds MUST have alternate links? References: <C311BE88-F950-11D8-91ED-003065EA6144@geckotribe.com> In-Reply-To: <C311BE88-F950-11D8-91ED-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Antone Roundy wrote: > It just seems to me that we're making a > requirement which limits Atom's flexibility without providing any > benefit. It's my personal opinion that defining Atom in terms of the resources listed in the charter buys us a lot of interop, because users have well-defined expectations about the content of Atom feeds. Do we even have a use-case here? (I realize we may) > Unless processing feeds without links would be non-trivially > difficult, why require links? > I think the term "processing" is misleading. Yes, parsing them and presenting them would be easy. Exactly what you would find inside is a different matter. At some point, "flexible and general" becomes "useless". Yes, this is a judgment call. You're free to propose amendments to the charter that would keep our problem tractable. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 21:24:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23413 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 21:24:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T1I8i8027462; Sat, 28 Aug 2004 18:18:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T1I8MD027461; Sat, 28 Aug 2004 18:18:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from dns02.mail.yahoo.co.jp (dns02.mail.yahoo.co.jp [211.14.15.205]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7T1I6Ro027451 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 18:18:07 -0700 (PDT) (envelope-from torumyax@yahoo.co.jp) Received: from unknown (HELO yahoo.co.jp) (210.151.150.2 with poptime) by dns02.mail.yahoo.co.jp with SMTP; 29 Aug 2004 01:17:59 -0000 X-Apparently-From: <torumyax@yahoo.co.jp> From: Toru Marumoto <torumyax@yahoo.co.jp> To: Asbjon Ulsberg <asbjorn@tigerstaden.no> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? Date: Sun, 29 Aug 2004 10:17:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 3.63 In-Reply-To: <opsdgwu6gsuvpchu@quark> References: <opsdgwu6gsuvpchu@quark> Message-Id: <CCC48D65E9463Ftorumyax@yahoo.co.jp> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit >> We're not here to deal with messaging. > >If you're so certain that entries without alternate, external >representations can't be syndication, why can't Atom deal with messaging >too? I think it's gonna be developers nightmare if alternate representation was not required. And it actually reduces the interoperability too. so let's keep it simple. (make it required) Toru Marumoto see you on the web! -------------------------------- __________________________________________________ GANBARE! NIPPON! Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE http://mail.ganbare-nippon.yahoo.co.jp/ From owner-atom-syntax@mail.imc.org Sat Aug 28 22:03:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24966 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 22:03:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T1rvnP030885; Sat, 28 Aug 2004 18:53:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T1rvd4030884; Sat, 28 Aug 2004 18:53:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7T1rvlK030867 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 18:53:57 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829015358.31350.qmail@web41206.mail.yahoo.com> Received: from [24.18.132.80] by web41206.mail.yahoo.com via HTTP; Sat, 28 Aug 2004 18:53:58 PDT Date: Sat, 28 Aug 2004 18:53:58 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: RE: URIs vs Strings To: bob@wyman.us, "'Julian Reschke'" <julian.reschke@gmx.de> Cc: "'Atom Syntax'" <atom-syntax@imc.org> In-Reply-To: <000a01c48d4f$7fa2b940$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Bob Wyman <bob@wyman.us> wrote: > Dare Obasanjo wrote: > > It seems you don't understand how canonicalization > works. > > To spell it out, Julian's point is that the > canonicalization > > of capitalizations does not apply to the path > component > > of HTTP URLs. > > It seems that you are too quick to jump on > potential error... If > you read my note you'll see I made *no* reference to > capitalization when > I mentioned "different ways to encode" the *path* > component. My comments > on case were restricted to the protocol and domain > fields. There are > many alternative encodings of the path element that > are eliminated by > canonicalization. Then what is the point of your example in your mail at http://www.imc.org/atom-syntax/mail-archive/msg09113.html First of all it contains bogus statements like "Windows systems are typically much more liberal in string matches than are Unix/Linux based systems when it comes to case-sensitivity" which I have no idea how to parse. Does it mean that String.Equals in the .NET Framework or strcmp in Visual C++ work differently than in Java or C on Unix systems? Anyway specifically in your mail you wrote "Then, newly discovered atom:id's are tested for uniqueness by doing a lookup in the database -- using a string key. All sorts of problems will arise if the string key is case-insensitive." Are you now claiming that you did not write this or I somehow misunderstood that what this implies about your belief in case insensitivity and canonicalization? Seriously, what does that statement mean if it doesn't imply that somehow URI canonicalization will make it possible to do case insensitive searches on URIs without problems? It's one thing to make an honest mistake about an arcane technology like URI canonicalization and another to pretend you didn't say something to mask ignorance about a particular topic. > > Your case of applications generating IDs from > database fields > > where the same ID has different cases will not be > helped by > canonicalization. > Read the example again. Canonicalization will > require lowercase > for protocol and domain components. Given that these > are part of the ID, > the probability of case-related errors is reduced -- > even though, as I > said in my note, it is not eliminated. WTF? So part of the ID will have normalized case. How exactly will that prevent case related errors in anything but HIGHLY CONTRIVED scenarios? Your argument makes sense if canonicalization converted all text to a single case but it doesn't which tremendously weakens your argument. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Sat Aug 28 22:04:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25052 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 22:04:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T1xFni031102; Sat, 28 Aug 2004 18:59:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T1xFEX031101; Sat, 28 Aug 2004 18:59:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7T1xFn7031091 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 18:59:15 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829015916.94580.qmail@web41212.mail.yahoo.com> Received: from [24.18.132.80] by web41212.mail.yahoo.com via HTTP; Sat, 28 Aug 2004 18:59:16 PDT Date: Sat, 28 Aug 2004 18:59:16 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Feeds MUST have alternate links? To: Tim Bray <Tim.Bray@Sun.COM>, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <50FBF734-F946-11D8-BAB9-000A95A51C9E@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Tim Bray <Tim.Bray@Sun.COM> wrote: > > I think Asbjørn and others have presented plausible > cases for feeds you > might create where there's not an instantly-obvious > choice for the > "alternate" link. Still, I think we should require > them; at least you > can point to an HTML page somewhere with a > human-readable description > saying "This feed describes variations in the > readings from the > potentiometer X328951 in rack 211-B" or something. > Among other things, > if you ran across such a feed in the wild and didn't > know what it was > about, having a standard link to follow to find out > would be nice. And > the cost is low. -Tim According to the protocol spec "alternate: The URI in the href attribute points to an alternate representation of the containing resource." Using this definition please tell me what the alternate should be for a feed for a mailing list or USENET newsgroup? Are you and Mark Pilgrim [who seems to be the other person strongly arguing for mandatory alternate links in feeds claiming that either (a) I have to create a web page for a mailing list or newsgroup before I can syndicate it with Atom or (b) this is not an expected use case for Atom? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Sat Aug 28 22:33:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25848 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 22:33:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2KrkU032387; Sat, 28 Aug 2004 19:20:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T2Krba032386; Sat, 28 Aug 2004 19:20:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2KrD0032377 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 19:20:53 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1FJS-0006CH-2G; Sun, 29 Aug 2004 02:20:58 +0000 Message-ID: <41313D89.8030502@franklinmint.fm> Date: Sat, 28 Aug 2004 22:20:57 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: Tim Bray <Tim.Bray@Sun.COM>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829015916.94580.qmail@web41212.mail.yahoo.com> In-Reply-To: <20040829015916.94580.qmail@web41212.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Dare Obasanjo wrote: > > --- Tim Bray <Tim.Bray@Sun.COM> wrote: > > >>I think Asbjørn and others have presented plausible >>cases for feeds you >>might create where there's not an instantly-obvious >>choice for the >>"alternate" link. Still, I think we should require >>them; at least you >>can point to an HTML page somewhere with a >>human-readable description >>saying "This feed describes variations in the >>readings from the >>potentiometer X328951 in rack 211-B" or something. >>Among other things, >>if you ran across such a feed in the wild and didn't >>know what it was >>about, having a standard link to follow to find out >>would be nice. And >>the cost is low. -Tim > > > According to the protocol spec > > "alternate: The URI in the href attribute points to an > alternate representation of the containing resource." > > Using this definition please tell me what the > alternate should be for a feed for a mailing list or > USENET newsgroup? Are you and Mark Pilgrim [who seems > to be the other person strongly arguing for mandatory > alternate links in feeds claiming that either (a) I > have to create a web page for a mailing list or > newsgroup before I can syndicate it with Atom or (b) > this is not an expected use case for Atom? > Use the 'nntp' or 'news' schemes. The current format draft requires only that the alternate link contain a URI. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 22:41:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26066 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 22:41:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2VY7A032847; Sat, 28 Aug 2004 19:31:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T2VY06032846; Sat, 28 Aug 2004 19:31:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41201.mail.yahoo.com (web41201.mail.yahoo.com [66.218.93.34]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7T2VY4v032840 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 19:31:34 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829023135.47648.qmail@web41201.mail.yahoo.com> Received: from [24.18.132.80] by web41201.mail.yahoo.com via HTTP; Sat, 28 Aug 2004 19:31:35 PDT Date: Sat, 28 Aug 2004 19:31:35 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Feeds MUST have alternate links? To: Robert Sayre <mint@franklinmint.fm> Cc: Tim Bray <Tim.Bray@Sun.COM>, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <41313D89.8030502@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Robert Sayre <mint@franklinmint.fm> wrote: > > > > > Using this definition please tell me what the > > alternate should be for a feed for a mailing list > or > > USENET newsgroup? Are you and Mark Pilgrim [who > seems > > to be the other person strongly arguing for > mandatory > > alternate links in feeds claiming that either (a) > I > > have to create a web page for a mailing list or > > newsgroup before I can syndicate it with Atom or > (b) > > this is not an expected use case for Atom? > > > > Use the 'nntp' or 'news' schemes. The current format > draft requires only > that the alternate link contain a URI. And I guess you suggest I use the 'mailto' scheme for mailing lists. That's fine, in which case the name alternate doesn't accurately describe the value or purpose of the attribute then. Secondly the value of the alternate spec is defined in the protocol spec[0] and it states "alternate: The URI in the href attribute points to an alternate representation of the containing resource." or are there drafts of the spec more recent than http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-01.txt [0] It is really irritating to have to jump to the protocol spec when looking up anything that has to do with values for the rel attribute of links. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Aug 28 22:50:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26383 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 22:50:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2fqoT033324; Sat, 28 Aug 2004 19:41:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T2fqck033322; Sat, 28 Aug 2004 19:41:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2fq5T033316 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 19:41:52 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1Fdl-0000yn-EC; Sun, 29 Aug 2004 02:41:57 +0000 Message-ID: <41314275.6010108@franklinmint.fm> Date: Sat, 28 Aug 2004 22:41:57 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: Tim Bray <Tim.Bray@Sun.COM>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829023135.47648.qmail@web41201.mail.yahoo.com> In-Reply-To: <20040829023135.47648.qmail@web41201.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Robert Sayre <mint@franklinmint.fm> wrote: > >> >>Use the 'nntp' or 'news' schemes. The current format >>draft requires only >>that the alternate link contain a URI. > > > And I guess you suggest I use the 'mailto' scheme for > mailing lists. No, I do not. I don't think that qualifies as an alternate representation, while Usenet URIs do, IMO. Perhaps you've caught me in some sort of contradiction here, but I think the intent of the spec is clear. > That's fine, in which case the name > alternate doesn't accurately describe the value or > purpose of the attribute then. Secondly the value of > the alternate spec is defined in the protocol spec[0] > and it states If you don't have an alternate, I don't have an answer. Alternate representations seem to be an integral part of syndication. > > "alternate: The URI in the href attribute points to an > alternate representation of the containing resource." > > or are there drafts of the spec more recent than > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-01.txt There is no more recent draft. I believe the IETF will delete 01 when 02 is made available. > > [0] It is really irritating to have to jump to the > protocol spec when looking up anything that has to do > with values for the rel attribute of links. I agree with you 100% and I have consistently advocated moving that section to the format spec. I would support "PaceLinkRelationsInFormat". Robert Sayre From owner-atom-syntax@mail.imc.org Sat Aug 28 23:05:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26840 for <atompub-archive@lists.ietf.org>; Sat, 28 Aug 2004 23:05:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2rsLU033769; Sat, 28 Aug 2004 19:53:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T2rsD5033768; Sat, 28 Aug 2004 19:53:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail58-s.fg.online.no (mail58-s.fg.online.no [148.122.161.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T2rrcV033757 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 19:53:54 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from mail.online.no (ti132110a080-2253.bb.online.no [80.212.216.205]) by mail58.fg.online.no (8.12.11/8.12.11) with ESMTP id i7T2rjKa016702; Sun, 29 Aug 2004 04:53:48 +0200 (MEST) Date: Sun, 29 Aug 2004 04:53:43 +0200 To: "Dare Obasanjo" <kpako@yahoo.com>, Atom-syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829015916.94580.qmail@web41212.mail.yahoo.com> From: "Arve Bersvendsen" <arve@virtuelvis.com> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdg3nt0r6dxgxk@mail.online.no> In-Reply-To: <20040829015916.94580.qmail@web41212.mail.yahoo.com> User-Agent: Opera M2/7.53 (Win32, build 3850) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 18:59:16 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> wrote: > Using this definition please tell me what the > alternate should be for a feed for a mailing list or > USENET newsgroup? I can't answer for mailing lists, but Usenet has the news: and nntp: URL schemes for accessing messages. See sections 3.6 and 3.7 of RFC 1738. (I still do not support mandatory links to alternate content.) -- Arve Bersvendsen http://www.virtuelvis.com http://www.bersvendsen.com From owner-atom-syntax@mail.imc.org Sun Aug 29 00:11:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29186 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 00:11:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T3vJP6037962; Sat, 28 Aug 2004 20:57:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T3vJoK037960; Sat, 28 Aug 2004 20:57:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T3vIjk037954 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 20:57:19 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 29 Aug 2004 14:04:21 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 29 Aug 2004 13:56:58 +1000 Subject: Re: PaceContentSrc From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BD57912A.2ACDE%eric.scheid@ironclad.net.au> In-Reply-To: <001201c48d40$dbe50820$6400a8c0@wyman.us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +1 to optional content indirection. Note, since this suggests that implementations would automatically retrieve resources from heretofore unseen URIs that there is a security issue, and should be noted in the spec. Examples: <entry> <content src="javascript:evil(1);" /> </entry> <entry> <content src="file:format%20c" /> </entry> (both not actual exploits, I would hope) e. From owner-atom-syntax@mail.imc.org Sun Aug 29 01:07:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01857 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 01:07:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T4x4Zo041648; Sat, 28 Aug 2004 21:59:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T4x4fo041647; Sat, 28 Aug 2004 21:59:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T4x361041641 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 21:59:03 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 68262 invoked by uid 17064); 29 Aug 2004 04:59:10 -0000 Received: from unknown (HELO [192.168.0.2]) ([81.51.236.206]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <antone@geckotribe.com>; 29 Aug 2004 04:59:10 -0000 In-Reply-To: <70D258AC-F94B-11D8-91ED-003065EA6144@geckotribe.com> References: <70D258AC-F94B-11D8-91ED-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <262A4D4E-F978-11D8-ADE0-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Antone Roundy <antone@geckotribe.com> From: Henry Story <henry.story@bblfish.net> Subject: Re: It's the entry, Stupid! ;-) [1] Date: Sun, 29 Aug 2004 06:59:03 +0200 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 29 Aug 2004, at 01:39, Antone Roundy wrote: > > On Saturday, August 28, 2004, at 05:01 PM, Henry Story wrote: >>>> a feed is just a pointer to a bunch of entries... >>>> Each entry is a resource (REST), where we can >>>> find all the information about the entry itself. >>> This would work, technically, however, I don't think it is >>> likely to become accepted practice since it would result in quite a >>> few >>> additional network roundtrips. >> >> I think on the contrary that the RESTful way I propose is going to be >> much more efficient network wise. I was convinced of this by Ken >> MacLeod during a long conversation on Atom irc a couple of months >> ago. He helped me rebuild my model quite dramatically. Here are some >> things to keep in mind. >> >> (1). With HTTP 1.1 Persistent connections only one tcp connection is >> needed to get all the data from a feed. If the client does not find >> some of the entries in its database it can request them in the same >> tcp connection. >> > ...assuming that all the data is on the same server. yes, good point. > > Rather than building pointer-only feeds into the format, The system I propose [2] is quite flexible, and I think Atom as it is can also be that flexible. It does not require pointer only feeds. It allows them. Which is really handy for all feeds in which the feed and the entry are on the same machine, which is going to be a large chunk of the cases. The important thing I ask for is that all entries have their own URIs. All entries should be resources. But feeds can add more information if they wish. The title, the author, the summary.... If they want the feed can contain *all* the entry information. It will be a much bulkier download of course, and much less cache-able. (I even allow for all the entries, with all their history to be in one large file [3]. ) It is also possible for the aggregator to place a copy of the Entry, on its own machine. That is why we have ids that don't change. It would be correct behavior in that case for the aggregator to have that entry point to the original entry. Which is not so different from having it point to the original feed, except for it being a little more consistent with putting the emphasis on Entries rather than on feeds. I also understand that in that case it would also be good practice to have the copy of the entry point to the original feed from which this was found, as a further point of interest. > thus requiring clients that don't support the API to be able to handle > them, it might be better to do such things via the API. For example, > we might define methods to query for a list of the most recent IDs > (which could be checked against your cache to see which are new), and > a method to query for a set of entries (by ID), which would be > returned in the standard feed format. > Henry http://bblfish.net/ [1] http://www.imc.org/atom-syntax/mail-archive/msg04596.html [2] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html [3] http://bblfish.net/work/atom-owl/2004-08-12/AllInOneDatabase.n3 From owner-atom-syntax@mail.imc.org Sun Aug 29 01:10:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01901 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 01:10:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T52tWM042300; Sat, 28 Aug 2004 22:02:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T52tN7042299; Sat, 28 Aug 2004 22:02:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T52top042291 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 22:02:55 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7T53253023500 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 23:03:02 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I360009IZD1LU@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 28 Aug 2004 23:03:01 -0600 (MDT) Received: from [192.168.1.15] ([216.113.204.14]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I3600BA4ZD0LJ@mail.sun.net> for atom-syntax@imc.org; Sat, 28 Aug 2004 23:03:01 -0600 (MDT) Date: Sat, 28 Aug 2004 22:02:58 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Feeds MUST have alternate links? In-reply-to: <1123422.1093735883140.JavaMail.dtcd@mac.com> To: Atom-Syntax Syntax <atom-syntax@imc.org> Message-id: <B1F39AA2-F978-11D8-BAB9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> <1123422.1093735883140.JavaMail.dtcd@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7T52top042292 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Hmm, this is an interesting discussion, and upon reviewing our charter, I don't think it really provides a slam-dunk case for either side to tell the other to shut up. We have seen interesting examples from Dare and Asbjørn of places where Atom might well be a good fit but there's no obvious, natural candidate for the alternate link. So this is a benefit of not requiring the alternate link. OK, then, let's do some cost-benefit analysis: what's the cost? If the cost is zero, or we come to generally believe that it's lower than the benefit, then the idea looks attractive. I'm not asking this question rhetorically; if it's been addressed on the list I missed it (perfectly possible). Put another way, I think it's worth investing some discussion on the technical trade-offs here rather than charter language and the definition of the word "syndication". -Tim From owner-atom-syntax@mail.imc.org Sun Aug 29 01:17:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02228 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 01:17:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T5A53k043735; Sat, 28 Aug 2004 22:10:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T5A5MH043732; Sat, 28 Aug 2004 22:10:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T5A3ZW043721 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 22:10:04 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7T5AAil011585 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 23:10:11 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3600AJBZOYEV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 28 Aug 2004 23:10:10 -0600 (MDT) Received: from [192.168.1.15] ([216.113.204.14]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I3600BBDZOXLJ@mail.sun.net> for atom-syntax@imc.org; Sat, 28 Aug 2004 23:10:10 -0600 (MDT) Date: Sat, 28 Aug 2004 22:10:07 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: PaceProtocolDesignTeam2 revised In-reply-to: <4131135A.70805@franklinmint.fm> To: Atom Syntax <atom-syntax@imc.org> Message-id: <B1B85060-F979-11D8-BAB9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4131135A.70805@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Aug 28, 2004, at 4:20 PM, Robert Sayre wrote: > I've revised the Pace, removing any assertions about consensus. Note > that debate on PUT/DELETE, etc. would be off-topic for the proposed > design team list (but not atom-syntax). This seems really counter-intuitive: the principal goal of having the design team is to attract people to the discussion who care about protocol issues but don't have time or patience to put up with our endless torrents of verbiage about IDs and dates and so on. So, it seems that the question of how best to use HTTP is one of the issues that this kind of person will care about. I don't understand how ruling it out of bounds is going to help. -Tim From owner-atom-syntax@mail.imc.org Sun Aug 29 01:35:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03064 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 01:35:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T5SgaH047418; Sat, 28 Aug 2004 22:28:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T5Sgrp047417; Sat, 28 Aug 2004 22:28:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T5SfB8047409 for <atom-syntax@imc.org>; Sat, 28 Aug 2004 22:28:41 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1IFB-0007qL-St; Sun, 29 Aug 2004 05:28:46 +0000 Message-ID: <4131698D.9060607@franklinmint.fm> Date: Sun, 29 Aug 2004 01:28:45 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray <Tim.Bray@Sun.COM> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceProtocolDesignTeam2 revised References: <4131135A.70805@franklinmint.fm> <B1B85060-F979-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <B1B85060-F979-11D8-BAB9-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 28, 2004, at 4:20 PM, Robert Sayre wrote: > >> I've revised the Pace, removing any assertions about consensus. Note >> that debate on PUT/DELETE, etc. would be off-topic for the proposed >> design team list (but not atom-syntax). > > > This seems really counter-intuitive: the principal goal of having the > design team is to attract people to the discussion who care about > protocol issues but don't have time or patience to put up with our > endless torrents of verbiage about IDs and dates and so on. Many interested in the protocol have no tolerance for endless torrents on PUT/DELETE vs. SOAP vs. custom headers. What are we going to do, disallow PUT and DELETE? They'll be there no matter what. > So, it > seems that the question of how best to use HTTP is one of the issues > that this kind of person will care about. I don't understand how ruling > it out of bounds is going to help. PaceProtocolDesignTeam takes the position that the implementation choices it presents are syntactic sugar. PaceProtocolDesignTeam2 takes that to heart, and puts it out of bounds. That is, discussion of HTTP trade-offs is prohibited until a coherent method of working with GET/POST/PUT/DELETE is worked out. None of the other methods proposed have anything on REST-with-4-verbs, IMO, other than the fact they work with incomplete HTTP implementations (compelling, admittedly). Robert Sayre From owner-atom-syntax@mail.imc.org Sun Aug 29 05:06:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25733 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 05:06:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T8hujK015092; Sun, 29 Aug 2004 01:43:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T8huKm015091; Sun, 29 Aug 2004 01:43:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7T8htvh015007 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 01:43:55 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 3055 invoked by uid 65534); 29 Aug 2004 08:43:42 -0000 Received: from pD9FF0984.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.9.132) by mail.gmx.net (mp007) with SMTP; 29 Aug 2004 10:43:42 +0200 X-Authenticated: #1915285 Message-ID: <41319734.6010700@gmx.de> Date: Sun, 29 Aug 2004 10:43:32 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <988F08AC-F6DC-11D8-ADE0-000A95D9FA7A@bblfish.net> <412D10B0.1010008@gmx.de> <1093498986.3389.8.camel@homer> <14be96d3040826071922d4fd90@mail.gmail.com> <412E0ACD.4080200@internetalchemy.org> <14be96d30408260926c798363@mail.gmail.com> <412E267D.4050109@internetalchemy.org> <412E28B5.6030507@franklinmint.fm> <412E437C.9080501@internetalchemy.org> <412E48B6.3020603@franklinmint.fm> <opsddow706uvpchu@quark> <476b71e80408270456f06f3f@mail.gmail.com> <412F42D1.5060103@cwru.edu> <DC8868AA-F857-11D8-8440-000A95DC3D90@mac.com> <opsdew3ogcuvpchu@quark> <1f2ed5cd040828012461fa49d7@mail.gmail.com> <opsdfq3ciyuvpchu@quark> <413055AB.6060800@gmx.de> <1f2ed5cd04082811454a98439b@mail.gmail.com> <4130D374.8030507@gmx.de> <opsdgl3lgcuvpchu@quark> In-Reply-To: <opsdgl3lgcuvpchu@quark> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Sat, 28 Aug 2004 20:48:20 +0200, Julian Reschke > <julian.reschke@gmx.de> wrote: > >> It's the producer's job to ensure that the IDs make sense. > > > And you don't think c14n is a step in the right direction there? No, not at all. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sun Aug 29 05:15:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25952 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 05:15:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T8uwkE019727; Sun, 29 Aug 2004 01:56:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T8uwdc019726; Sun, 29 Aug 2004 01:56:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7T8uvFd019682 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 01:56:57 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 32210 invoked by uid 65534); 29 Aug 2004 08:56:49 -0000 Received: from pD9FF0984.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.9.132) by mail.gmx.net (mp014) with SMTP; 29 Aug 2004 10:56:49 +0200 X-Authenticated: #1915285 Message-ID: <41319A43.3020703@gmx.de> Date: Sun, 29 Aug 2004 10:56:35 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: URIs vs Strings References: <20040828142830.97184.qmail@web41205.mail.yahoo.com> <1F505BEC8EDB69C9D26F7076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <4130AFA8.60503@gmx.de> <1f2ed5cd0408281202521612b0@mail.gmail.com> <4130D9F4.90507@gmx.de> <opsdgmjagsuvpchu@quark> In-Reply-To: <opsdgmjagsuvpchu@quark> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Sat, 28 Aug 2004 21:16:04 +0200, Julian Reschke > <julian.reschke@gmx.de> wrote: > >> Any comparison that involves URI-specific knowledge will be less strict. > > > Who has said anything about URI scheme-specific comparison? Producers > know which URI scheme they provide in atom:id's. They should then know > what it takes to canonicalize them. Consumers should compare them > char-by-char no matter what. Where does the URI scheme-specific > comparison come into play? Again. As long as consumers do what the spec says, canonicalization doesn't buy you anything at all, as recipients compare as strings. The trouble starts when they don't, in which case there is a large number of ways to get it wrong. Canonicalization will eliminate *some* cases, but not all. So if we have broken consumers, will canonicalization make them less broken? Possibly. However - if the spec mentions canonicalization for producers, there's a real risk that developers of consumers will get their comparisons wrong because they think that what they get will always be canonicalized, and - making the spec strict (just specify string comparison) and prodiving test cases (test atom feeds) can ensure that consumers indeed *do* get this right. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sun Aug 29 05:23:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26159 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 05:23:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T94bBP021933; Sun, 29 Aug 2004 02:04:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T94b7Y021932; Sun, 29 Aug 2004 02:04:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T94aek021923 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 02:04:36 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 58461 invoked by uid 17064); 29 Aug 2004 09:04:37 -0000 Received: from unknown (HELO [192.168.0.2]) ([81.51.236.206]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <asbjorn@tigerstaden.no>; 29 Aug 2004 09:04:37 -0000 In-Reply-To: <opsdgt5vvzuvpchu@quark> References: <1f2ed5cd040828140049dc8b3e@mail.gmail.com> <opsdgt5vvzuvpchu@quark> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6EB10C88-F99A-11D8-ADE0-000A95D9FA7A@bblfish.net> Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> From: Henry Story <henry.story@bblfish.net> Subject: Re: Purpose of PersonConstruct Date: Sun, 29 Aug 2004 11:04:28 +0200 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7T94aek021924 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On 29 Aug 2004, at 01:28, Asbjørn Ulsberg wrote: > > On Sat, 28 Aug 2004 23:00:06 +0200, Danny Ayers > <danny.ayers@gmail.com> wrote: > >> They all boil down to identifying the person entity, but how that's >> done is another matter. [...] Wouldn't it be better to allow an >> sha1's version of the address as an alternative? > > I've thought about this for a while, and many others have probably > too, but since I know as much as virtually nothing about FOAF, I have > no idea how to attack the problem. > > Can't you, or anyone else with FOAF-knowledge, write up a pace, blog > entry or whatever, that explains how FOAF can be used to identify > authors in Atom? It would be very useful. I have recently written up [1] an example of FOAF in action with a RDFised version of Atom, using N3 notation [2]. That should help give you some context which you are familiar with. Take for example my entry [3] ----------8<-------------------------------------------- @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix : <http://bblfish.net/work/atom-owl/2004-08-12/Atom.owl#> . <> a :Entry ; :alternate [ a :Link ; :href <blogexample.html#entry.2004-07-12-1935.n3> ; :mime-type "text/html"^^xsd:string ; :text "html blog entry"^^xsd:string ] ; :author [ a <http://xmlns.com/foaf/0.1/Person> ; <http://xmlns.com/foaf/0.1/homepage> <http://bblfish.net/> ; <http://xmlns.com/foaf/0.1/mbox> <mailto:henry.story@bblfish.net> ; <http://xmlns.com/foaf/0.1/name> "Henry Story"^^xsd:string ] ; :content [ a :Content ; :data "All of the content here is freely licenced under the gpl for the code, and the <a href='http://creativecommons.org/licenses/by-sa/2.0/'>Attribution- ShareAlike 2.0</a> Creative Commons license, for the text. "^^xsd:string ; :mime-type "text/html"^^xsd:string ] ; :copyright <http://creativecommons.org/licenses/by-sa/2.0/> ; :created "2004-07-12T19:35:00+0200"^^xsd:dateTime ; :entry-version <tag:bblfish.net/20040712/1935/blog1#version1> ; :id <tag:bblfish.net/20040712/1935/blog1> ; :title [ a :Content ; :data "Copyrights"^^xsd:string ; :mime-type "text/simple"^^xsd:string ] . ----------8<-------------------------------------------- This structure should be quite familiar to an Atomist. The first line says that this file (<>) is an Entry. This file has as alternate representation [4] at blogexample.html#entry.2004-07-12-1935.n3 The author is a FOAF structure. You can click on those links to get the full definition of each property. This does not yet make full use of the what is available in foaf, but it gives you the basics. Some nice applications of these FOAF relationships would be to be allow blog readers to find feeds of friends of a friend (FFOAF). Henry Story http://bblfish.net/ > -- > Asbjørn Ulsberg -=|=- asbjornu@hotmail.com > «He's a loathsome offensive brute, yet I can't look away» [1] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html http://bblfish.net/work/atom-owl/2004-08-12/ [2] http://infomesh.net/2002/notation3/ [3] http://bblfish.net/work/atom-owl/2004-08-12/entry.2004-07-12-1935.n3 [4] http://bblfish.net/work/atom-owl/2004-08-12/Atom.owl#alternate From owner-atom-syntax@mail.imc.org Sun Aug 29 05:50:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27449 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 05:50:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T9V54o029801; Sun, 29 Aug 2004 02:31:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T9V5iM029800; Sun, 29 Aug 2004 02:31:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T9V2Jk029765 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 02:31:02 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so71282rnb for <atom-syntax@imc.org>; Sun, 29 Aug 2004 02:30:58 -0700 (PDT) Received: by 10.38.206.45 with SMTP id d45mr943631rng; Sun, 29 Aug 2004 02:30:58 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sun, 29 Aug 2004 02:30:58 -0700 (PDT) Message-ID: <1f2ed5cd04082902307f6c348b@mail.gmail.com> Date: Sun, 29 Aug 2004 11:30:58 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: Julian Reschke <julian.reschke@gmx.de> Subject: Re: URIs vs Strings Cc: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <41319A43.3020703@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040828142830.97184.qmail@web41205.mail.yahoo.com> <1F505BEC8EDB69C9D26F7076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <4130AFA8.60503@gmx.de> <1f2ed5cd0408281202521612b0@mail.gmail.com> <4130D9F4.90507@gmx.de> <opsdgmjagsuvpchu@quark> <41319A43.3020703@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Sun, 29 Aug 2004 10:56:35 +0200, Julian Reschke <julian.reschke@gmx.de> wrote > Again. > > As long as consumers do what the spec says, canonicalization doesn't buy > you anything at all, as recipients compare as strings. Errm, yes it does, because there are loads of equivalent URIs comparisons that will produce false negatives if the consumer does string comparison, but that would match correctly if they were canonicalized before publication (and the consumer does string comparison). > The trouble starts when they don't, in which case there is a large > number of ways to get it wrong. Canonicalization will eliminate *some* > cases, but not all. If consumers approximate the comparisons in rfc2396bis, then canonicalization will help in a large proportion of cases. If they don't, they are seriously broken. > So if we have broken consumers, will canonicalization make them less > broken? Possibly. > However > > - if the spec mentions canonicalization for producers, there's a real > risk that developers of consumers will get their comparisons wrong > because they think that what they get will always be canonicalized, and > > - making the spec strict (just specify string comparison) and prodiving > test cases (test atom feeds) can ensure that consumers indeed *do* get > this right. Or it may lead to consumers thinking that producers all use string comparison, and get it wrong for those that don't. There's only a limited distance you can get in predicting non-compliant developer behaviour. I think we should guess on the side that favours doing the Right Thing. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Aug 29 06:07:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28122 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 06:07:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T9kcNM033479; Sun, 29 Aug 2004 02:46:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7T9kcJq033478; Sun, 29 Aug 2004 02:46:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7T9kbq9033452 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 02:46:38 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so71441rnb for <atom-syntax@imc.org>; Sun, 29 Aug 2004 02:46:33 -0700 (PDT) Received: by 10.38.1.72 with SMTP id 72mr940612rna; Sun, 29 Aug 2004 02:46:33 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sun, 29 Aug 2004 02:46:33 -0700 (PDT) Message-ID: <1f2ed5cd040829024623e839d6@mail.gmail.com> Date: Sun, 29 Aug 2004 11:46:33 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: Henry Story <henry.story@bblfish.net> Subject: Re: Purpose of PersonConstruct Cc: Atom Syntax <atom-syntax@imc.org>, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> In-Reply-To: <6EB10C88-F99A-11D8-ADE0-000A95D9FA7A@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd040828140049dc8b3e@mail.gmail.com> <opsdgt5vvzuvpchu@quark> <6EB10C88-F99A-11D8-ADE0-000A95D9FA7A@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Sun, 29 Aug 2004 11:04:28 +0200, Henry Story <henry.story@bblfish.net> wrote: > I have recently written up [1] an example of FOAF in action with a > RDFised version of Atom, using N3 notation [2]. That should help give > you some context which you are familiar with. Take for example my entry > [3] Thanks Henry, there's less of a mismatch than I thought. Looking at your example (snippet below) I'm reminded that there is a more direct map to the Atom structure in RDF(/XML), it could look something like : <entry> <author rdf:parseType="Resource"> <name>Jane</name> </author> </entry> Here's a (marginally) more FOAFish version: <entry> <author> <Person> <name>Jane</name> </Person> </author> <entry> If you knew (from the spec/RDF schema) that the range of the atom:author property was foaf:Person, then I believe these two would be equivalent. Cheers, Danny. > <> a :Entry ; > :author [ a <http://xmlns.com/foaf/0.1/Person> ; > <http://xmlns.com/foaf/0.1/homepage> > <http://bblfish.net/> ; > <http://xmlns.com/foaf/0.1/mbox> > <mailto:henry.story@bblfish.net> ; > <http://xmlns.com/foaf/0.1/name> > "Henry Story"^^xsd:string > ] ; -- http://dannyayers.co From owner-atom-syntax@mail.imc.org Sun Aug 29 06:27:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28657 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 06:27:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TAGNK8041399; Sun, 29 Aug 2004 03:16:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TAGN4C041398; Sun, 29 Aug 2004 03:16:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TAGLwu041377 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 03:16:22 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 29 Aug 2004 20:23:18 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 29 Aug 2004 20:15:54 +1000 Subject: Re: Feeds MUST have alternate links? From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BD57E9FA.2ADA4%eric.scheid@ironclad.net.au> In-Reply-To: <20040829015916.94580.qmail@web41212.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 29/8/04 11:59 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote: > (a) I have to create a web page for a mailing list or newsgroup before I can > syndicate it with Atom or (b) this is not an expected use case for Atom? > <snark> also publish it as RSS </snark> e. From owner-atom-syntax@mail.imc.org Sun Aug 29 07:01:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00057 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 07:01:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TAplwo049422; Sun, 29 Aug 2004 03:51:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TAplYg049421; Sun, 29 Aug 2004 03:51:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TApknR049391 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 03:51:46 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829105143.21819.qmail@web41215.mail.yahoo.com> Received: from [24.18.132.80] by web41215.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 03:51:43 PDT Date: Sun, 29 Aug 2004 03:51:43 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: URIs vs Strings To: Danny Ayers <danny.ayers@gmail.com>, Julian Reschke <julian.reschke@gmx.de> Cc: "Asbjørn" Ulsberg <asbjorn@tigerstaden.no>, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <1f2ed5cd04082902307f6c348b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Danny Ayers <danny.ayers@gmail.com> wrote: > > > > As long as consumers do what the spec says, > canonicalization doesn't buy > > you anything at all, as recipients compare as > strings. > > Errm, yes it does, because there are loads of > equivalent URIs > comparisons that will produce false negatives if the > consumer does > string comparison, but that would match correctly if > they were > canonicalized before publication (and the consumer > does string > comparison). Instead of talking in hypotheticals can you actually name some real life instances when this has actually been a problem? You do realize that for the past five years or more people have been exchanging XML documents with URIs as identifiers [any RDF or XML document with namespaces which includes 50% - 75% of the RSS feeds in existence] over the Web and these string comparison problems you claim will be an issue have not been. > Or it may lead to consumers thinking that producers > all use string > comparison, and get it wrong for those that don't. > There's only a > limited distance you can get in predicting > non-compliant developer > behaviour. I think we should guess on the side that > favours doing the > Right Thing. Basically you're trying to spec behavior for people who won't read the spec? So now producers have to do extra, unnecessary work just in case some consumers don't read the spec. (a) That's the most ass backwards thing I've heard in a while (b) if the consumers are implemented incorrectly they deserve the broken behavior that ensues ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Sun Aug 29 07:08:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00273 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 07:08:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TB0Tnb051559; Sun, 29 Aug 2004 04:00:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TB0Tkb051558; Sun, 29 Aug 2004 04:00:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TB0SmX051515 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 04:00:28 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 92FFD7C1EE; Sun, 29 Aug 2004 13:50:30 +0200 (CEST) To: "Toru Marumoto" <torumyax@yahoo.co.jp> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <opsdgwu6gsuvpchu@quark> <CCC48D65E9463Ftorumyax@yahoo.co.jp> Message-ID: <opsdhqanrnuvpchu@quark> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Sun, 29 Aug 2004 13:02:37 +0200 In-Reply-To: <CCC48D65E9463Ftorumyax@yahoo.co.jp> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sun, 29 Aug 2004 10:17:11 +0900, Toru Marumoto <torumyax@yahoo.co.jp> wrote: > I think it's gonna be developers nightmare if alternate representation > was not required. Huh? Surely, you're talking about consumer developers, then? > And it actually reduces the interoperability too. Why? How? > so let's keep it simple. (make it required) Simple for whom? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 29 07:23:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00970 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 07:23:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TBFuWq055434; Sun, 29 Aug 2004 04:15:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TBFu4i055433; Sun, 29 Aug 2004 04:15:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TBFtVX055405 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 04:15:55 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 88FA17C1EE; Sun, 29 Aug 2004 14:06:06 +0200 (CEST) Date: Sun, 29 Aug 2004 13:18:17 +0200 To: "Robert Sayre" <mint@franklinmint.fm> Subject: Re: Close PaceErrVerb Cc: Atom-Syntax <atom-syntax@imc.org> References: <412E1CA2.9030404@franklinmint.fm> <opsdeqlbx5uvpchu@quark> <412FA168.40708@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdhq0rrnuvpchu@quark> In-Reply-To: <412FA168.40708@franklinmint.fm> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Fri, 27 Aug 2004 17:02:32 -0400, Robert Sayre <mint@franklinmint.fm> wrote: > ErrorURI is not required to be the same URI as the original request > because this is not a realistic requirement for a large proportion of > Atom deployment scenarios. But could ErrorURI be the same as the original request's URI by default, then? So you have three layers of URI's, in this order of precendence: 1. The original request's URI 2. The URI in <link rel="service.error"> 3. The URI in the HTTP header 'X-Atom-Error'. I also find it better to give this order of precedence than to say that «if X is different from Y, a report MUST NOT be sent». If the HTTP header always has higher precedence than the two other URI's, it doesn't matter what the others are, and you don't have to compare them and do lots of other complex stuff. Just find the URI with the highest precedence and GRUMBLE that one. > Also, note that a second URI is likely more robust than sending a > request to the resource that is known to be misconfigured. Yes, that's probably true. > PaceServiceError has just recently incorporated an "ErrVerb". You can > examine the numerous contributions from this list in the Notes and > Discussion sections [0]. You may also wish to examine the precedents > cited there: Pingback, Mozilla, and ebXML. If you're still interested, > you can examine the 158 edits that the Pace has undergone[1]. I have, and I still think it needs some improvements to be simpler. Other than that, it's good. We can probably close PaceErrVerb. On a side note: Why do you use the word «SHALL» instead of «SHOULD» some places? I know they mean the same (also by RFC 2119 terms), but isn't «SHOULD» more used and known to people? I also find that «SHOULD» reads better in the places you've used «SHALL». The request SHALL be a GRUMBLE. No other methods are currently specified for this URI. could be rewritten to The request to the ErrorURI SHOULD be a GRUMBLE. No other methods are currently specified for this URI. It would also be useful to mention the HTTP method «GRUMBLE» in all places where «request» is mentioned. E.g.: If the Atom Document violates any validity constraints of the Atom Format Specification, a request(5.6.3) SHOULD be sent to the ErrorURI. could be: If the Atom Document violates any validity constraints of the Atom Format Specification, a GRUMBLE request (5.6.3) SHOULD be sent to the ErrorURI. Just to make it clearer that it is the GRUMBLE method that should be used in all error requests. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 29 07:47:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01755 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 07:47:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TBdJJp060381; Sun, 29 Aug 2004 04:39:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TBdJak060379; Sun, 29 Aug 2004 04:39:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TBdIKE060353 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 04:39:19 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id DA28E7C1EE; Sun, 29 Aug 2004 14:29:29 +0200 (CEST) Date: Sun, 29 Aug 2004 13:41:45 +0200 To: "Robert Sayre" <mint@franklinmint.fm>, "Dare Obasanjo" <kpako@yahoo.com> Subject: Re: Feeds MUST have alternate links? Cc: "Tim Bray" <Tim.Bray@sun.com>, Atom-Syntax <atom-syntax@imc.org> References: <20040829015916.94580.qmail@web41212.mail.yahoo.com> <41313D89.8030502@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdhr3voluvpchu@quark> In-Reply-To: <41313D89.8030502@franklinmint.fm> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 22:20:57 -0400, Robert Sayre <mint@franklinmint.fm> wrote: >> (a) I have to create a web page for a mailing list or newsgroup before >> I can syndicate it with Atom > > Use the 'nntp' or 'news' schemes. The current format draft requires only > that the alternate link contain a URI. But what is then the actual _use_ of <link rel="alternate">? I mean, if the intent is that human readers should be able to click the URI and then get some human readable resource thrown up in a browser widget or whatever, how is this going to work for any other URI scheme than HTTP? Are we expecting Atom readers (humans) to have user agents for all these different schemes installed, or are we expecting Atom clients (applications) to build in support for all these schemes? If the answer to the above questions are «no», then can someone please tell me what good <link rel="alternate" type="text/plain" href="nntp://news.example.com/alt.example/2342" /> or <link rel="alternate" type="text/plain" href="news:opsdgm9crnuvpchu@example.com" /> is supposed to do to anyone? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 29 07:53:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02074 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 07:53:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TBj8c2061667; Sun, 29 Aug 2004 04:45:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TBj8pk061665; Sun, 29 Aug 2004 04:45:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TBj75t061635 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 04:45:07 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 626D17C1EE; Sun, 29 Aug 2004 14:35:18 +0200 (CEST) To: "Robert Sayre" <mint@franklinmint.fm> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829023135.47648.qmail@web41201.mail.yahoo.com> <41314275.6010108@franklinmint.fm> Message-ID: <opsdhsdk06uvpchu@quark> Date: Sun, 29 Aug 2004 13:47:34 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <41314275.6010108@franklinmint.fm> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 22:41:57 -0400, Robert Sayre <mint@franklinmint.fm> wrote: >> And I guess you suggest I use the 'mailto' scheme for >> mailing lists. > > No, I do not. I don't think that qualifies as an alternate > representation, while Usenet URIs do, IMO. Okay, so in a non-archived mailing list, what are you going to do, then? Do you have to create an HTML archive for the sole purpose of accomodating the specification? > Perhaps you've caught me in some sort of contradiction here, but I > think the intent of the spec is clear. The original intent is clear. The problem is that it constrains to a major degree what Atom can be used for. > If you don't have an alternate, I don't have an answer. Alternate > representations seem to be an integral part of syndication. It might be an integral part of RSS syndication, but not syndication in any other aspect of real life (where the word actually comes from. It wasn't created by Dave Winer) and thus should it not be in Atom either, imo. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 29 08:02:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02416 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 08:02:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TBmaoj062828; Sun, 29 Aug 2004 04:48:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TBmaYI062827; Sun, 29 Aug 2004 04:48:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TBmZnT062806 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 04:48:35 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TBmhDV020870; Sun, 29 Aug 2004 07:48:43 -0400 Message-ID: <4131C292.3090409@intertwingly.net> Date: Sun, 29 Aug 2004 07:48:34 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid <eric.scheid@ironclad.net.au> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceContentSrc References: <BD57912A.2ACDE%eric.scheid@ironclad.net.au> In-Reply-To: <BD57912A.2ACDE%eric.scheid@ironclad.net.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Eric Scheid wrote: > <content src="javascript:evil(1);" /> Note: javascript is not an IANA registered scheme. http://www.iana.org/assignments/uri-schemes - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 08:09:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03024 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 08:09:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TC1QhA065244; Sun, 29 Aug 2004 05:01:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TC1QnX065243; Sun, 29 Aug 2004 05:01:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TC1P6K065223 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 05:01:26 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 8A3127C1EE; Sun, 29 Aug 2004 14:51:36 +0200 (CEST) Date: Sun, 29 Aug 2004 14:03:56 +0200 To: "Tim Bray" <Tim.Bray@sun.com> Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax <atom-syntax@imc.org> References: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> <1123422.1093735883140.JavaMail.dtcd@mac.com> <B1F39AA2-F978-11D8-BAB9-000A95A51C9E@sun.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdhs4ud6uvpchu@quark> In-Reply-To: <B1F39AA2-F978-11D8-BAB9-000A95A51C9E@sun.com> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sat, 28 Aug 2004 22:02:58 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote: > OK, then, let's do some cost-benefit analysis: what's the cost? The cost of having to provide alternate representations for all resources exposed as Atom documents is huge. Think of non-archived mailing lists. My personal CD collection. News events of a football match. TV listings. «Last played» lists for radio. «Next 10» lists for radio. Also, if a URI scheme or format is not mandated, I don't understand the intent of <link rel="alternate">. I mean, if I can just put <link rel="alternate" type="text/javascript" href="javascript:alert('hello')" /> in my feeds to satisfy the specification, who gains from that? At least, if the specification mandated 'text/html' (or variations of it) for @type and the HTTP scheme for @href, it would be useful as an easy-retrievable, human readable, alternative representation. If all URI schemes and all content types are allowed, then what is the point? I'd also like to not that Dare, who creates a highly used RSS and Atom aggregator, don't see the point in having this alternate link. If this link isn't useful to an aggregator or aggregator users, and don't cause anything to break if it's missing, why do we need it? Which cat are we tying up for what reason here? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 29 08:26:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03659 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 08:26:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TCHFMQ068365; Sun, 29 Aug 2004 05:17:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TCHF0i068364; Sun, 29 Aug 2004 05:17:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TCHERK068352 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 05:17:14 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] ([66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TCHOOo022337; Sun, 29 Aug 2004 08:17:24 -0400 Message-ID: <4131C94C.7080005@intertwingly.net> Date: Sun, 29 Aug 2004 08:17:16 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray <Tim.Bray@Sun.COM> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceProtocolDesignTeam2 revised References: <4131135A.70805@franklinmint.fm> <B1B85060-F979-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <B1B85060-F979-11D8-BAB9-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 28, 2004, at 4:20 PM, Robert Sayre wrote: > >> I've revised the Pace, removing any assertions about consensus. Note >> that debate on PUT/DELETE, etc. would be off-topic for the proposed >> design team list (but not atom-syntax). > > This seems really counter-intuitive: the principal goal of having the > design team is to attract people to the discussion who care about > protocol issues but don't have time or patience to put up with our > endless torrents of verbiage about IDs and dates and so on. So, it > seems that the question of how best to use HTTP is one of the issues > that this kind of person will care about. I don't understand how ruling > it out of bounds is going to help. -Tim The format document has enough coverage to be useful at the moment. Presumably some of the existing paces will make it even better. By contrast, the protocol document is demonstrably incomplete. And I have seen no evidence that there are paces in the pipeline which will close this gap. I'd like to see closing the gap be the principle goal of this design group. Discussion on alternatives to PUT and DELETE can continue in parallel. In particular, I would encourage Paces to be written to cover any other alternative syntax that anybody would like to propose. I would not oppose the spinning off of a design group (either now or at some point in the future) for that specific topic, but I would prefer not to dilute the purpose of this design group. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 09:05:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05642 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 09:05:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TCqKXn073775; Sun, 29 Aug 2004 05:52:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TCqKfF073774; Sun, 29 Aug 2004 05:52:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TCqJwM073764 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 05:52:19 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TCqUrv024487; Sun, 29 Aug 2004 08:52:30 -0400 Message-ID: <4131D185.6050707@intertwingly.net> Date: Sun, 29 Aug 2004 08:52:21 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray <Tim.Bray@Sun.COM> CC: Atom-Syntax Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> <1123422.1093735883140.JavaMail.dtcd@mac.com> <B1F39AA2-F978-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <B1F39AA2-F978-11D8-BAB9-000A95A51C9E@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Tim Bray wrote: > > Hmm, this is an interesting discussion, and upon reviewing our charter, > I don't think it really provides a slam-dunk case for either side to > tell the other to shut up. > > We have seen interesting examples from Dare and Asbjørn of places where > Atom might well be a good fit but there's no obvious, natural candidate > for the alternate link. So this is a benefit of not requiring the > alternate link. OK, then, let's do some cost-benefit analysis: what's > the cost? If the cost is zero, or we come to generally believe that > it's lower than the benefit, then the idea looks attractive. I'm not > asking this question rhetorically; if it's been addressed on the list I > missed it (perfectly possible). > > Put another way, I think it's worth investing some discussion on the > technical trade-offs here rather than charter language and the > definition of the word "syndication". -Tim Fair enough. My preference is that the alternate link (possibly renamed) remains required. The feed readers that I am aware of all provide the ability to launch the alternate view of a feed. By contrast, each has to provide a set of logic to search for a number of different ways in which the alternate view of an entry may (or may not be) provided. To put this in a larger context: RSS 1.0 has a tiny core and lots of extensions. The other RSS fork took some of these interesting ideas and put them into the core[1] - as options. I claim that having notions such as ids (in rss 2.0) and dates (in both) as options hurts interoperability. Similar observation on there being two ways in the core of RSS 2.0 to specify an item permalink, both optional. A final note: to date, this question has been phrased a bit too hypthetically for me - it seems to be of the nature "how would I handle a set of feeds that nobody is currently providing". By contrast, however, something that WOULD attract my attention is somebody saying "here is a set of feeds that I would like to provide that I can't provide in a valid way according to any of the available RSS specifications." - Sam Ruby [1] http://groups.yahoo.com/group/syndication/message/218 From owner-atom-syntax@mail.imc.org Sun Aug 29 09:45:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07826 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 09:45:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TDbPea081576; Sun, 29 Aug 2004 06:37:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TDbPSH081575; Sun, 29 Aug 2004 06:37:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TDbOOP081566 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 06:37:24 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829133722.28705.qmail@web41209.mail.yahoo.com> Received: from [24.18.132.80] by web41209.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 06:37:22 PDT Date: Sun, 29 Aug 2004 06:37:22 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Feeds MUST have alternate links? To: Sam Ruby <rubys@intertwingly.net>, Tim Bray <Tim.Bray@Sun.COM> Cc: Atom-Syntax Syntax <atom-syntax@imc.org> In-Reply-To: <4131D185.6050707@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Sam Ruby <rubys@intertwingly.net> wrote: > Fair enough. > > My preference is that the alternate link (possibly > renamed) remains > required. The feed readers that I am aware of all > provide the ability > to launch the alternate view of a feed. By > contrast, each has to > provide a set of logic to search for a number of > different ways in which > the alternate view of an entry may (or may not be) > provided. The feed readers you are aware of can launch the website for a particular feed. It seems very limiting to assume that only websites can syndicate content. > To put this in a larger context: RSS 1.0 has a tiny > core and lots of > extensions. The other RSS fork took some of these > interesting ideas and > put them into the core[1] - as options. I claim > that having notions > such as ids (in rss 2.0) and dates (in both) as > options hurts > interoperability. Similar observation on there > being two ways in the > core of RSS 2.0 to specify an item permalink, both > optional. http://www.datanation.com/fallacies/falsean.htm Analogies are a weak way to debate. Claiming that since not having required IDs and dates is bad for interop does not translate to not requiring some other field being bad for interop. Please describe how interop is hurt by not having this field instead of arguing by analogy. > A final note: to date, this question has been > phrased a bit too > hypthetically for me - it seems to be of the nature > "how would I handle > a set of feeds that nobody is currently providing". > By contrast, > however, something that WOULD attract my attention > is somebody saying > "here is a set of feeds that I would like to provide > that I can't > provide in a valid way according to any of the > available RSS > specifications." This isn't a hypothetical question. Google is already providing Atom feeds for USENET so this isn't hypothetical. However since all the feeds they'd syndicate show up in http://groups.google.com they don't have this problem since they can always point to that site. I'm currently implementing NNTP support in RSS Bandit and currently would like to use the same archive format for syndication feeds and USENET. Currently I only plan to use it as a synchronization source since they upped the space limit to 250MB. However it is conceivable that Hotmail support could end up in RSS Bandit in a year or so. Again I'd like to have a uniform archive format. Also, there are feeds for this mailing list syndicated today but since it has an online archive the feeds can point here. Similarly someone at MSFT is working on a patch that allows RSS Bandit to communicate with Hotmail. Basically it seems you are claiming that that unless a mailing list or newsgroup is archived on the Web it can't be syndicated in Atom. That sounds like an arbitrary and unnecessary restriction. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sun Aug 29 10:12:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09612 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 10:12:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE6E6w084860; Sun, 29 Aug 2004 07:06:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TE6E4W084859; Sun, 29 Aug 2004 07:06:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE6Dhc084853 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 07:06:13 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TE6OZ5028685 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:06:24 -0400 Message-ID: <4131E2D7.9010603@intertwingly.net> Date: Sun, 29 Aug 2004 10:06:15 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax <atom-syntax@imc.org> Subject: PaceServiceElement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +1 - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 10:13:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09682 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 10:13:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE1cB3084205; Sun, 29 Aug 2004 07:01:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TE1cOX084203; Sun, 29 Aug 2004 07:01:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE1bsc084195 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 07:01:37 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] ([66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TE1mmT028479; Sun, 29 Aug 2004 10:01:48 -0400 Message-ID: <4131E1C2.9080105@intertwingly.net> Date: Sun, 29 Aug 2004 10:01:38 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: Atom-Syntax Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829133722.28705.qmail@web41209.mail.yahoo.com> In-Reply-To: <20040829133722.28705.qmail@web41209.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: >>To put this in a larger context: RSS 1.0 has a tiny >>core and lots of >>extensions. The other RSS fork took some of these >>interesting ideas and >>put them into the core[1] - as options. I claim >>that having notions >>such as ids (in rss 2.0) and dates (in both) as >>options hurts >>interoperability. Similar observation on there >>being two ways in the >>core of RSS 2.0 to specify an item permalink, both >>optional. > > http://www.datanation.com/fallacies/falsean.htm > > Analogies are a weak way to debate. Claiming that > since not having required IDs and dates is bad for > interop does not translate to not requiring some other > field being bad for interop. > > Please describe how interop is hurt by not having this > field instead of arguing by analogy. It was not my intent to argue by analogy. I thought I was clear: I was trying to explain the larger context in which I was looking at this issue. However, since I was less than successful the first time, let me try again: My overall thought process when modelling a syntax for interop loosely goes this: 1) can this feature be REQUIRED? 2) if not, can this feature be placed in an EXTENSION? 3) if none of the above, then consider an OPTION. Any individual optional element may be defensible, what would concern me is a pattern of replacing required elements with optional elements. More specifically, what I am looking for is a compelling reason why feed links can't be required and can't be an extension. Different people may have different thought processes, but those are mine. FWIW. >>A final note: to date, this question has been >>phrased a bit too >>hypthetically for me - it seems to be of the nature >>"how would I handle >>a set of feeds that nobody is currently providing". >>By contrast, >>however, something that WOULD attract my attention >>is somebody saying >>"here is a set of feeds that I would like to provide >>that I can't >>provide in a valid way according to any of the >>available RSS >>specifications." > > This isn't a hypothetical question. Google is already > providing Atom feeds for USENET so this isn't > hypothetical. However since all the feeds they'd > syndicate show up in http://groups.google.com they > don't have this problem since they can always point to > that site. I'm currently implementing NNTP support in > RSS Bandit and currently would like to use the same > archive format for syndication feeds and USENET. > > Currently I only plan to use it as a synchronization > source since they upped the space limit to 250MB. > However it is conceivable that Hotmail support could > end up in RSS Bandit in a year or so. Again I'd like > to have a uniform archive format. Also, there are > feeds for this mailing list syndicated today but since > it has an online archive the feeds can point here. > Similarly someone at MSFT is working on a patch that > allows RSS Bandit to communicate with Hotmail. I accept that an archive format based on Atom may have different requirements (particularly with respect to cardinalities) than a syndication format. You and I have discussed this before - in the context of dates. > Basically it seems you are claiming that that unless a > mailing list or newsgroup is archived on the Web it > can't be syndicated in Atom. That sounds like an > arbitrary and unnecessary restriction. Please don't put words in my mouth. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 10:13:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09716 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 10:13:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE1Ujs084185; Sun, 29 Aug 2004 07:01:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TE1UlI084179; Sun, 29 Aug 2004 07:01:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TE1Ta0084145 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 07:01:29 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 11500 messnum 5140527 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 29 Aug 2004 14:01:25 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail13.svc.cra.dublin.eircom.net (qp 11500) with SMTP; 29 Aug 2004 14:01:25 -0000 Message-ID: <4131E1B4.7040206@dehora.net> Date: Sun, 29 Aug 2004 15:01:24 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax <atom-syntax@imc.org> Subject: atom:id - comparison and generation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Having watched this thread on URIs v Strings, http://www.imc.org/atom-syntax/mail-archive/msg08886.html go on for many posts and decline into an intellectually slothful shouting match, I suspect the debate is not framed in a manner that can produce a satisfactory outcome, something I indicated in that thread. Here's why URIs v Strings will go no-where. It's a false dilemma. Arguing to URIs v Strings is like arguing to Waves v Particles but worse, without any rigor for either position. The truth is we require IDs to be both URIs and Strings depending on context. I'd like to suggest any further such discussion on atom identifiers be done in terms of Comparison and Generation. Here is what I perceive as consensus. Generation: Use of functions which return URIs for use as atom:id. Comparison Use of functions which compare pairs of atom:id constructs as case-sensitive Strings. So, what are we arguing about? The remaining issues seems to be in concern about confusing implementors or users, and ascertaining either post processing rules on generators or pre-processing rules on comparators to reduce the likelihood of mismatches. One issue seems to be that treating URIs as not-URIs (Strings) is confusing. I think this might be true, but I think it is mostly true because we start threads focusing on URIs and Strings themselves and not on how identifiers are to be /used/. It seems that people have generally accepted that URIs generators are to be used, but it's my belief that much confusion evaporates when you explain atom:id in use contexts rather than variant formats. The primary issue appears to be canonicalization - some people feel it will be probably be helpful, some people feel it probably won't be helpful and there was at least one view that it would possibly be detrimental. IMHO, that comes down to: 1. Say generation SHOULD post-process to canonical form before emitting 2. Say generation MUST post-process to canonical form before emitting 3. Say nothing about canonical forms for generation I did not see corresponding positions around comparison pre-processing. My opinion is that 1 is a sufficiently appeasing non-decision that allows us to move on. I would not be inclined to keep Postel's law in mind when trying to establish an optimal tradeoff, allocation of burden, or just trying to think clearly about this issue. If that's heresy so be it, but my opinion is that that law can be used here to support conflicting arguments and thus isn't specifically helpful. FYI: This was the summary of consensus roughly 10 days ago, http://www.imc.org/atom-syntax/mail-archive/msg08572.html I have not included views that suggests atom:id is not a useful construct as designed since it is a separate matter to the above and is mostly being discussed in a separate thread. I haven't seen any alternative proposals to atom:id, but in not keeping up with the wiki lately I might have missed them. [I have seen an alternative approach from Bob Wyman but I don't think he's proposed it for Atom use.] cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 29 10:13:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09742 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 10:13:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE5AnL084830; Sun, 29 Aug 2004 07:05:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TE5A3L084829; Sun, 29 Aug 2004 07:05:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TE595B084823 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 07:05:10 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TE5LnX028635 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:05:21 -0400 Message-ID: <4131E297.6010705@intertwingly.net> Date: Sun, 29 Aug 2004 10:05:11 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax <atom-syntax@imc.org> Subject: PacePersonLinks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +1 - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 10:18:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10465 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 10:18:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TEC55j085092; Sun, 29 Aug 2004 07:12:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TEC5cs085091; Sun, 29 Aug 2004 07:12:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TEC4e3085079 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 07:12:05 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 8096 messnum 7748928 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 29 Aug 2004 14:12:01 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail01.svc.cra.dublin.eircom.net (qp 8096) with SMTP; 29 Aug 2004 14:12:01 -0000 Message-ID: <4131E430.1080904@dehora.net> Date: Sun, 29 Aug 2004 15:12:00 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Purpose of PersonConstruct References: <1f2ed5cd040828140049dc8b3e@mail.gmail.com> In-Reply-To: <1f2ed5cd040828140049dc8b3e@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Danny Ayers wrote: > * providing ownership details (i.e. copyright on the content) > * providing contact details (i.e. how to get in touch with the person) > * providing data for entry processing (e.g. finding entries by the same author) * exposing those who post anonymously. cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 29 10:42:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11800 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 10:42:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TEYAQA086239; Sun, 29 Aug 2004 07:34:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TEYAPF086238; Sun, 29 Aug 2004 07:34:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail43-s.fg.online.no (mail43-s.fg.online.no [148.122.161.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TEY8Aq086228 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 07:34:09 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from mail.online.no (ti132110a080-3244.bb.online.no [80.212.220.172]) by mail43.fg.online.no (8.12.11/8.12.11) with ESMTP id i7TEXsgI006857; Sun, 29 Aug 2004 16:33:58 +0200 (CEST) Date: Sun, 29 Aug 2004 16:33:50 +0200 To: "Sam Ruby" <rubys@intertwingly.net>, Atom-syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829133722.28705.qmail@web41209.mail.yahoo.com> <4131E1C2.9080105@intertwingly.net> From: "Arve Bersvendsen" <arve@virtuelvis.com> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdhz2o0b6dxgxk@mail.online.no> In-Reply-To: <4131E1C2.9080105@intertwingly.net> User-Agent: Opera M2/7.53 (Win32, build 3850) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sun, 29 Aug 2004 10:01:38 -0400, Sam Ruby <rubys@intertwingly.net> wrote: > More specifically, what I am looking for is a compelling reason why feed > links can't be required and can't be an extension. * Because there already are uses _in the wild_ with RSS for which there is no sensible alternate content. See <URL:http://www.imc.org/atom-syntax/mail-archive/msg09150.html> * Because people (on this list, even) see near-term future uses of Atom where an alternate representation is not appropriate. -- Arve Bersvendsen http://www.virtuelvis.com http://www.bersvendsen.com From owner-atom-syntax@mail.imc.org Sun Aug 29 10:47:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11957 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 10:47:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TEdtmj086447; Sun, 29 Aug 2004 07:39:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TEdtu0086446; Sun, 29 Aug 2004 07:39:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TEdsbc086423 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 07:39:55 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 45080 messnum 6485571 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 29 Aug 2004 14:39:50 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail12.svc.cra.dublin.eircom.net (qp 45080) with SMTP; 29 Aug 2004 14:39:50 -0000 Message-ID: <4131EAB5.8050907@dehora.net> Date: Sun, 29 Aug 2004 15:39:49 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <opsdefxdk4uvpchu@quark> <CBC48C5EB9FAD9torumyax@yahoo.co.jp> <opsdej8nj9uvpchu@quark> <412F804A.6000405@intertwingly.net> <1123422.1093735883140.JavaMail.dtcd@mac.com> <41311891.30609@franklinmint.fm> In-Reply-To: <41311891.30609@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Robert Sayre wrote: > If the entry doesn't have > an alternate representation that can be identified by a URI, it isn't > syndication--it's messaging. It's incidental, but I don't agree with that characterization. cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 29 10:50:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12121 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 10:50:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TEiPt6086604; Sun, 29 Aug 2004 07:44:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TEiPsI086603; Sun, 29 Aug 2004 07:44:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TEiOtc086594 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 07:44:25 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 20305 messnum 2861015 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 29 Aug 2004 14:44:21 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail07.svc.cra.dublin.eircom.net (qp 20305) with SMTP; 29 Aug 2004 14:44:21 -0000 Message-ID: <4131EBC4.5050003@dehora.net> Date: Sun, 29 Aug 2004 15:44:20 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829015916.94580.qmail@web41212.mail.yahoo.com> <41313D89.8030502@franklinmint.fm> <opsdhr3voluvpchu@quark> In-Reply-To: <opsdhr3voluvpchu@quark> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > If the answer to the above questions are «no», then can someone please > tell me what good > > <link rel="alternate" type="text/plain" > href="nntp://news.example.com/alt.example/2342" /> > > or > > <link rel="alternate" type="text/plain" > href="news:opsdgm9crnuvpchu@example.com" /> > > is supposed to do to anyone? I imagine it relies on the idea that a number of client readers embed browsers or browser components to render web content rather than code the rendering from scratch. The browsers in question can switch based on the protocol. cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 29 12:06:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15970 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:06:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFqq6D090516; Sun, 29 Aug 2004 08:52:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TFqqOY090515; Sun, 29 Aug 2004 08:52:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFqo9m090501 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 08:52:51 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 172FA7C1F9; Sun, 29 Aug 2004 18:42:53 +0200 (CEST) Date: Sun, 29 Aug 2004 17:54:59 +0200 To: =?iso-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax <atom-syntax@imc.org> References: <20040829015916.94580.qmail@web41212.mail.yahoo.com> <41313D89.8030502@franklinmint.fm> <opsdhr3voluvpchu@quark> <4131EBC4.5050003@dehora.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdh3txgcuvpchu@quark> In-Reply-To: <4131EBC4.5050003@dehora.net> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sun, 29 Aug 2004 15:44:20 +0100, Bill de hÓra <bill@dehora.net> wrote: > I imagine it relies on the idea that a number of client readers embed > browsers or browser components to render web content rather than code > the rendering from scratch. This is the machine-to-human use case of Atom. It also implies that such browser widgets are available for the given platform and environment. Shouldn't it be possible to create Atom user agents that don't have a visual rendering API, like console applications, for instance? Either way, there are a lot of compelling use cases for Atom that is _not_ machine-to-human, but machine-to-machine. And even in many machine-to-human scenarios, the humans really don't care about alternative representations, as Arve told about his feed reading statistics. > The browsers in question can switch based on the protocol. Not all of them can. How many support the NNTP scheme, for example? Or NEWS, for that matter? What other schemes would be acceptable, and which would not be? Should the acceptable schemes be enumerated in the specification, or should it be silent, but still require <link rel="alternate">? If so, it is perfectly allowable to say: <link rel="alternate" type="application/rtsl" href="rtsp://example.com/example_stream.rm" /> RTSP is a registered URI scheme: <url: http://www.iana.org/assignments/uri-schemes> <url: http://www.ietf.org/rfc/rfc2326.txt> What browser widgets support the RTSP URI scheme? Or the VEMMI scheme? Or the SIP, SIPS, TEL, FAX or MODEM schemes? If <link rel="alternate"> is going to be useful, the allowed or recommended schemes and content types needs to be enumerated. I would still not support it being required, but then it would at least purport the right intent. (If I have understood the intent correctly, it is to give an alternate, easy-retrievable and human readable representation of Atom resources. If the intent is something else, please let me know. If someone thinks this intent is met without requiring URI schemes and content types, please tell me about that as well.) -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 29 12:09:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16163 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:09:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFv5mD090889; Sun, 29 Aug 2004 08:57:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TFv5mm090888; Sun, 29 Aug 2004 08:57:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFv4Xi090866 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 08:57:04 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2A53B7C1F9; Sun, 29 Aug 2004 18:47:15 +0200 (CEST) Date: Sun, 29 Aug 2004 17:59:20 +0200 To: =?iso-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> Subject: Re: atom:id - comparison and generation Cc: Atom-Syntax <atom-syntax@imc.org> References: <4131E1B4.7040206@dehora.net> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdh306u4uvpchu@quark> In-Reply-To: <4131E1B4.7040206@dehora.net> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sun, 29 Aug 2004 15:01:24 +0100, Bill de hÓra <bill@dehora.net> wrote: > 1. Say generation SHOULD post-process to canonical form before > emitting > > [....] > > My opinion is that 1 is a sufficiently appeasing non-decision that > allows us to move on. I agree with this. I actually think everyone who wants c14n agrees with this. The ones that have been silent about this option are the ones that are against c14n. If they aren't comfortable with «SHOULD post-process to c14n», could they at least say so? That is, just '-1' on Bill's proposal here. Would it be useful to have a survey on this, just to see how the rough consensus is? I have really no idea what everyone on atom-syntax feels about this, since there are only about six people that have been active in this discussion. A survey would not conclude anything, but make people's stand clearer. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 29 12:14:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16693 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:14:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TG5TgX091755; Sun, 29 Aug 2004 09:05:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TG5TXT091754; Sun, 29 Aug 2004 09:05:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TG5SsP091740 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:05:29 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 6038 invoked by uid 65534); 29 Aug 2004 16:05:25 -0000 Received: from dsl-082-082-077-023.arcor-ip.net (EHLO localhost) (82.82.77.23) by mail.gmx.net (mp027) with SMTP; 29 Aug 2004 18:05:25 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Mark Pilgrim <pilgrim@gmail.com> Cc: atom-syntax@imc.org Subject: Re: Feeds MUST have alternate links? Date: Sun, 29 Aug 2004 18:05:10 +0200 Message-ID: <4146ee49.311371859@smtp.bjoern.hoehrmann.de> References: <87smabifw7.fsf@nwalsh.com> <opsdbsf4uouvpchu@quark> <412DBD74.9040904@intertwingly.net> <opsddo6ujtuvpchu@quark> <14be96d304082706186c6b8a00@mail.gmail.com> <41354676.202872184@smtp.bjoern.hoehrmann.de> <14be96d3040828152660a60bd4@mail.gmail.com> In-Reply-To: <14be96d3040828152660a60bd4@mail.gmail.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit * Mark Pilgrim wrote: >> >If you're looking for a syndication format that's even looser and has >> >even fewer required elements than RSS, you're in the wrong place. >> >> It is >> >> http://www.google.com/search?q=intitle%3A%22untitled+document%22 >> http://www.google.com/search?q=intitle%3A%22Welcome+to+Adobe+GoLive%22 >>  http://www.google.com/search?q=intitle%3A%22Willkommen+bei+Adobe+GoLive%22 >> ... >> >> pointless to require presence of meta data that is not required for >> interoperability, and making meta data up just to satisfy obscure >> requirements in a specification actually reduces the value of the >> meta data when used properly. > >That won't help you make your case at all. Channel title has been >required in every version of RSS since 1999, and in CDF before that. >Are there thousands of "Untitled blog" feeds out there? No. Just like there are not millions of home pages without a customized title either, most documents lacking a proper title are sub-pages; but there are thousands of feed entries with titles like * [Insert Witty Title Here] * insert clever title here * [Click to Insert Title] * Click To Add Title * Insert Title Here * Untitled document * ADD A TITLE HERE * Untitled Entry * (no title) * No Title * Untitled * Title * ... some even have something like * Can't think of a good title * heh...to tired to think of a good title * I had a really good title for this. Really, I did. * No good title comes to mind... * Monday (Because I Couldn't Think of a Good Title) * I can never think of good subject titles * uh... can't think of a good title... * No Good Titles Before 10am * I suck at making up titles, so just insert something good here. * Can't Think of a good title...sorry * dont really have a good subject title lol * ... I wonder whether these are two classes of software, such that require changing the "default" title and such that do not... So, what exactly is the point of mandating meta data if software or people do not provide it properly but rather some "junk" instead just to satisfy the requirement? >Not all metadata is burdensome. Some is reasonable to require. RFC 2119 requires, [...] Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) [...] Is it required for interoperation that Atom documents have an alternate representation and refer to it? Does it have potential for causing harm when such information is missing? No. Such a requirement is as pointless as the requirement that renders http://diveintomark.org/ non-conforming, section 14.2.1 of the HTML 4.01 Recommendation. I am as surprised that feeds are required to have alternate representations as most standards savy authors are surprised by that requirement; conformance requirements should be obvious, not surprising -- they'll be ignored otherwise. From owner-atom-syntax@mail.imc.org Sun Aug 29 12:16:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16772 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:16:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TG2PC1091368; Sun, 29 Aug 2004 09:02:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TG2Pqv091361; Sun, 29 Aug 2004 09:02:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TG2O4j091344 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:02:24 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by mail.pubsub.com (Postfix) with ESMTP id 5F6DE171DD6; Sun, 29 Aug 2004 12:02:21 -0400 (EDT) Reply-To: <bobwyman@pubsub.com> From: "Bob Wyman" <bobwyman@pubsub.com> To: "'Dare Obasanjo'" <kpako@yahoo.com>, <bob@wyman.us>, "'Julian Reschke'" <julian.reschke@gmx.de> Cc: "'Atom Syntax'" <atom-syntax@imc.org> Subject: RE: URIs vs Strings Date: Sun, 29 Aug 2004 12:04:41 -0400 Organization: PubSub Concepts, Inc. Message-ID: <000a01c48de1$e555f3f0$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20040829015358.31350.qmail@web41206.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > It's one thing to make an honest mistake about an > arcane technology like URI canonicalization and > another to pretend you didn't say something to mask > ignorance about a particular topic. You seem so intent on proving me wrong that you continue to mischaracterize what I have written. It's sort of like listening to republicans on a Sunday morning TV talk show... I have never suggested that canonicalization would impact the case of characters in the path component of URI's. I have only mentioned case when speaking of the protocol and domain fields. As to the path component, there are still many alternate ways to encode a single string. For instance, everyone is familiar, I think with such the problems with "%20" etc... If not, please review C14N. You should not have any difficulty coming up with at least 2^6 different ways to encode "foobar" when it appears in a path. However, only one of those semantically equivelant methods would be permitted by C14N rules. >First of all it contains bogus statements like "Windows systems > are typically much more liberal in string matches than are > Unix/Linux based systems when it comes to case-sensitivity" File names in Windows systems have always been case-insensitive. This goes back to Windows' roots in DOS and probably reaches back to DOS's roots in the non-Unix operating systems (many from Digital) that influenced its early definition. On the other hand, Unix has always had case-sensitive file names. I believe that the case-insensitivity of DOS and Windows file names has influenced DOS/Windows developers to implement case-insensitivity as the default string match in other areas matches over the years. > Does it mean that String.Equals in the .NET > Framework or strcmp in Visual C++ work differently > than in Java or C on Unix systems? I was speaking of Windows itself -- not code that has been layered on top of it in recent years. It remains the case that canonicalization drastically reduces the number of ways in which any particular URI can be written. In some cases, this is done by restricting case, in others, it is done by restricting or requiring the use of a particluar method of encoding a character. The result in variety *will* result in fewer opportunities for error. That is the whole point of C14N. bob wyman -----Original Message----- From: Dare Obasanjo [mailto:kpako@yahoo.com] Sent: Saturday, August 28, 2004 9:54 PM To: bob@wyman.us; 'Julian Reschke' Cc: 'Atom Syntax' Subject: RE: URIs vs Strings --- Bob Wyman <bob@wyman.us> wrote: > Dare Obasanjo wrote: > > It seems you don't understand how canonicalization > works. > > To spell it out, Julian's point is that the > canonicalization > > of capitalizations does not apply to the path > component > > of HTTP URLs. > > It seems that you are too quick to jump on > potential error... If > you read my note you'll see I made *no* reference to capitalization > when I mentioned "different ways to encode" the *path* > component. My comments > on case were restricted to the protocol and domain > fields. There are > many alternative encodings of the path element that > are eliminated by > canonicalization. Then what is the point of your example in your mail at http://www.imc.org/atom-syntax/mail-archive/msg09113.html First of all it contains bogus statements like "Windows systems are typically much more liberal in string matches than are Unix/Linux based systems when it comes to case-sensitivity" which I have no idea how to parse. Does it mean that String.Equals in the .NET Framework or strcmp in Visual C++ work differently than in Java or C on Unix systems? Anyway specifically in your mail you wrote "Then, newly discovered atom:id's are tested for uniqueness by doing a lookup in the database -- using a string key. All sorts of problems will arise if the string key is case-insensitive." Are you now claiming that you did not write this or I somehow misunderstood that what this implies about your belief in case insensitivity and canonicalization? Seriously, what does that statement mean if it doesn't imply that somehow URI canonicalization will make it possible to do case insensitive searches on URIs without problems? It's one thing to make an honest mistake about an arcane technology like URI canonicalization and another to pretend you didn't say something to mask ignorance about a particular topic. > > Your case of applications generating IDs from > database fields > > where the same ID has different cases will not be > helped by > canonicalization. > Read the example again. Canonicalization will > require lowercase > for protocol and domain components. Given that these > are part of the ID, > the probability of case-related errors is reduced -- > even though, as I > said in my note, it is not eliminated. WTF? So part of the ID will have normalized case. How exactly will that prevent case related errors in anything but HIGHLY CONTRIVED scenarios? Your argument makes sense if canonicalization converted all text to a single case but it doesn't which tremendously weakens your argument. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Sun Aug 29 12:26:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18179 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:26:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGH9hm092622; Sun, 29 Aug 2004 09:17:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TGH9O7092621; Sun, 29 Aug 2004 09:17:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TGH7qw092614 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:17:08 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 12930 invoked by uid 65534); 29 Aug 2004 16:17:05 -0000 Received: from dsl-082-082-077-023.arcor-ip.net (EHLO localhost) (82.82.77.23) by mail.gmx.net (mp023) with SMTP; 29 Aug 2004 18:17:05 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Tim Bray <Tim.Bray@Sun.COM> Cc: Atom-Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? Date: Sun, 29 Aug 2004 18:16:49 +0200 Message-ID: <4147fed4.315607119@smtp.bjoern.hoehrmann.de> References: <87smabifw7.fsf@nwalsh.com> <opsdbsf4uouvpchu@quark> <412DBD74.9040904@intertwingly.net> <opsddo6ujtuvpchu@quark> <14be96d304082706186c6b8a00@mail.gmail.com> <41354676.202872184@smtp.bjoern.hoehrmann.de> <14be96d3040828152660a60bd4@mail.gmail.com> <opsdgsdxsxuvpchu@quark> <50FBF734-F946-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <50FBF734-F946-11D8-BAB9-000A95A51C9E@sun.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit * Tim Bray wrote: >I think Asbjørn and others have presented plausible cases for feeds you >might create where there's not an instantly-obvious choice for the >"alternate" link. Still, I think we should require them; at least you >can point to an HTML page somewhere with a human-readable description >saying "This feed describes variations in the readings from the >potentiometer X328951 in rack 211-B" or something. Users are going to get disappointed if such a document is sold to them as an alternate HTML representation of the feed and think twice about following such a link next time. This is very much like <img alt="*" ...> versus <img alt="rotating circle with fancy blue border" ...>. From owner-atom-syntax@mail.imc.org Sun Aug 29 12:34:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18632 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:34:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGPFwK093154; Sun, 29 Aug 2004 09:25:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TGPFSV093153; Sun, 29 Aug 2004 09:25:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TGPEFR093138 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:25:14 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 29123 invoked by uid 65534); 29 Aug 2004 16:25:12 -0000 Received: from dsl-082-082-077-023.arcor-ip.net (EHLO localhost) (82.82.77.23) by mail.gmx.net (mp018) with SMTP; 29 Aug 2004 18:25:12 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Robert Sayre <mint@franklinmint.fm> Cc: atom-syntax@imc.org Subject: Re: Feeds MUST have alternate links? Date: Sun, 29 Aug 2004 18:24:51 +0200 Message-ID: <414901f5.316408000@smtp.bjoern.hoehrmann.de> References: <20040829023135.47648.qmail@web41201.mail.yahoo.com> <41314275.6010108@franklinmint.fm> In-Reply-To: <41314275.6010108@franklinmint.fm> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit * Robert Sayre wrote: >If you don't have an alternate, I don't have an answer. Alternate >representations seem to be an integral part of syndication. The Atom Publishing Format *enables* syndication, but it is not limited to it, at least not as far as I can tell from our Charter. From owner-atom-syntax@mail.imc.org Sun Aug 29 12:37:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18750 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:37:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGSWGM093334; Sun, 29 Aug 2004 09:28:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TGSWrZ093333; Sun, 29 Aug 2004 09:28:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TGSUJe093317 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:28:31 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 12872 invoked by uid 65534); 29 Aug 2004 16:28:28 -0000 Received: from pD9FF0984.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.9.132) by mail.gmx.net (mp024) with SMTP; 29 Aug 2004 18:28:28 +0200 X-Authenticated: #1915285 Message-ID: <41320427.2050504@gmx.de> Date: Sun, 29 Aug 2004 18:28:23 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: atom:id - comparison and generation References: <4131E1B4.7040206@dehora.net> <opsdh306u4uvpchu@quark> In-Reply-To: <opsdh306u4uvpchu@quark> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Sun, 29 Aug 2004 15:01:24 +0100, Bill de hÓra <bill@dehora.net> wrote: > >> 1. Say generation SHOULD post-process to canonical form before >> emitting >> >> [....] >> >> My opinion is that 1 is a sufficiently appeasing non-decision that >> allows us to move on. > > > I agree with this. I actually think everyone who wants c14n agrees with > this. The ones that have been silent about this option are the ones > that are against c14n. If they aren't comfortable with «SHOULD > post-process to c14n», could they at least say so? That is, just '-1' > on Bill's proposal here. OK, -1. Reason: it makes the spec more complicated without having any effect when clients indeed implement string comparison. > ... Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sun Aug 29 12:47:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19157 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:47:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGdAMJ093853; Sun, 29 Aug 2004 09:39:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TGdAil093852; Sun, 29 Aug 2004 09:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGdA9s093843 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:39:10 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7TGd9us017774; Sun, 29 Aug 2004 12:39:10 -0400 (EDT) Received: from w2kbwyman (66-65-26-18.nyc.rr.com [66.65.26.18]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BPC22459 (AUTH bob@wyman.us); Sun, 29 Aug 2004 12:39:08 -0400 (EDT) Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "=?iso-8859-1?Q?'Asbj=F8rn_Ulsberg'?=" <asbjorn@tigerstaden.no>, "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" <bill@dehora.net> Cc: "'Atom-Syntax'" <atom-syntax@imc.org> Subject: RE: Feeds MUST have alternate links? Date: Sun, 29 Aug 2004 12:41:28 -0400 Message-ID: <000c01c48de7$084c81d0$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <opsdh3txgcuvpchu@quark> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7TGdA9s093847 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > Should the acceptable [URI] schemes be enumerated in the > specification...? Absolutely NO. Doing this would border on insanity. It is perfectly ok if the URI scheme used as an "alternate" is not supported by all clients. Heck, I can show you clients that process Atom feeds but don't support the http scheme! Some clients know what to do with nntp:, news:, http:, https:, and even rtsp: and gopher:. The fact that all clients won't know how to handle every scheme is not a bug. bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 29 12:49:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19265 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:49:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGhVjr093986; Sun, 29 Aug 2004 09:43:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TGhVTA093985; Sun, 29 Aug 2004 09:43:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGhUju093978 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:43:30 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TGhgGL002906; Sun, 29 Aug 2004 12:43:42 -0400 Message-ID: <413207B5.2050903@intertwingly.net> Date: Sun, 29 Aug 2004 12:43:33 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arve Bersvendsen <arve@virtuelvis.com> CC: Atom-syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829133722.28705.qmail@web41209.mail.yahoo.com> <4131E1C2.9080105@intertwingly.net> <opsdhz2o0b6dxgxk@mail.online.no> In-Reply-To: <opsdhz2o0b6dxgxk@mail.online.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Arve Bersvendsen wrote: > > On Sun, 29 Aug 2004 10:01:38 -0400, Sam Ruby <rubys@intertwingly.net> > wrote: > >> More specifically, what I am looking for is a compelling reason why >> feed links can't be required and can't be an extension. > > * Because there already are uses _in the wild_ with RSS for which there > is no sensible alternate content. See > <URL:http://www.imc.org/atom-syntax/mail-archive/msg09150.html> > * Because people (on this list, even) see near-term future uses of Atom > where an alternate representation is not appropriate. Perhaps I missed it, but I don't see an argument against making link an extension in the above? The down side of not having a link be required is that it opens up the possibility of there being multiple distinct ways to express the concept. There already is a syndication format where there is two distinct ways to express an entry permalink in the core, and a number of extensions which can be used to replace those core elements. Note that I am I'm not saying that we shouldn't do this here, but I am saying that we need to be careful and consider both the upsides and the downsides. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 12:56:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19674 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 12:56:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGnKIM094166; Sun, 29 Aug 2004 09:49:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TGnKOj094165; Sun, 29 Aug 2004 09:49:20 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGnKsw094150 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:49:20 -0700 (PDT) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id i7TGnGq13814 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:49:16 -0700 (PDT) Received: from aol.net ([10.169.192.22]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id I37W2301.N2X for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:49:15 -0700 Message-ID: <4132090E.8020304@aol.net> Date: Sun, 29 Aug 2004 09:49:18 -0700 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax <atom-syntax@imc.org> Subject: Re: atom:id - comparison and generation References: <4131E1B4.7040206@dehora.net> In-Reply-To: <4131E1B4.7040206@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > I'd like to suggest any further such discussion on atom identifiers be > done in terms of Comparison and Generation... > +1. > > 1. Say generation SHOULD post-process > to canonical form before emitting +1. (I have followed this thread, though not contributed to the discussion as there seemed to be plenty of discussion already.) -John http://journals.aol.com/panzerjohn/abstractioneer From owner-atom-syntax@mail.imc.org Sun Aug 29 13:03:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20132 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 13:03:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGsfSR094412; Sun, 29 Aug 2004 09:54:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TGsfPB094411; Sun, 29 Aug 2004 09:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TGsecf094405 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 09:54:40 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 08B864EFE3; Sun, 29 Aug 2004 12:54:41 -0400 (EDT) Date: Sun, 29 Aug 2004 12:54:40 -0400 From: Dan Brickley <danbri@w3.org> To: Bob Wyman <bob@wyman.us> Cc: "=?iso-8859-15?Q?'Asbj=F8rn?= Ulsberg'" <asbjorn@tigerstaden.no>, "'Bill de =?iso-8859-15?Q?h=D3ra'?=" <bill@dehora.net>, "'Atom-Syntax'" <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? Message-ID: <20040829165440.GD6435@homer.w3.org> References: <opsdh3txgcuvpchu@quark> <000c01c48de7$084c81d0$6400a8c0@wyman.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <000c01c48de7$084c81d0$6400a8c0@wyman.us> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit * Bob Wyman <bob@wyman.us> [2004-08-29 12:41-0400] > > Asbjørn Ulsberg wrote: > > Should the acceptable [URI] schemes be enumerated in the > > specification...? > Absolutely NO. Doing this would border on insanity. > It is perfectly ok if the URI scheme used as an "alternate" is > not supported by all clients. Heck, I can show you clients that process > Atom feeds but don't support the http scheme! > Some clients know what to do with nntp:, news:, http:, https:, > and even rtsp: and gopher:. The fact that all clients won't know how to > handle every scheme is not a bug. +1 Some things are best left to the marketplace... Dan From owner-atom-syntax@mail.imc.org Sun Aug 29 13:15:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20833 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 13:15:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TH8sFS094907; Sun, 29 Aug 2004 10:08:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TH8sK1094905; Sun, 29 Aug 2004 10:08:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TH8sO1094897 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:08:54 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829170852.89804.qmail@web41202.mail.yahoo.com> Received: from [24.18.132.80] by web41202.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 10:08:52 PDT Date: Sun, 29 Aug 2004 10:08:52 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Feeds MUST have alternate links? To: Sam Ruby <rubys@intertwingly.net> Cc: Atom-Syntax Syntax <atom-syntax@imc.org> In-Reply-To: <4131E1C2.9080105@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Sam Ruby <rubys@intertwingly.net> wrote: > > > > > Please describe how interop is hurt by not having > this > > field instead of arguing by analogy. > > It was not my intent to argue by analogy. I thought > I was clear: I was > trying to explain the larger context in which I was > looking at this > issue. However, since I was less than successful > the first time, let me > try again: > > My overall thought process when modelling a syntax > for interop loosely > goes this: > > 1) can this feature be REQUIRED? > 2) if not, can this feature be placed in an > EXTENSION? > 3) if none of the above, then consider an OPTION. Interesting. I have totally different approach. Like Anders Hejlsberg keeps telling us at work every feature should start with a 1000 points against. Add 1 for every good reason to have it, if you get to 0 then ship the feature otherwise it isn't worth the cost. It's a variation of "The hallmarks of a good design is when you have nothing left to take out". > I accept that an archive format based on Atom may > have different > requirements (particularly with respect to > cardinalities) than a > syndication format. You and I have discussed this > before - in the > context of dates. OK. > > Basically it seems you are claiming that that > unless a > > mailing list or newsgroup is archived on the Web > it > > can't be syndicated in Atom. That sounds like an > > arbitrary and unnecessary restriction. > > Please don't put words in my mouth. Fine, then what is your position on whether feeds like http://groups-beta.google.com/group/microsoft.public.xml/feed/msgs.xml and http://rss.groups.yahoo.com/group/rss-dev/rss should be possible for newsgroups and mailing lists that are not archived on some public website? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sun Aug 29 13:28:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21729 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 13:28:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THEUin095274; Sun, 29 Aug 2004 10:14:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7THEUV7095273; Sun, 29 Aug 2004 10:14:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7THETjG095262 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:14:29 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829171428.71291.qmail@web41203.mail.yahoo.com> Received: from [24.18.132.80] by web41203.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 10:14:28 PDT Date: Sun, 29 Aug 2004 10:14:28 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: RE: Feeds MUST have alternate links? To: bob@wyman.us, "'Asbjørn_Ulsberg'" <asbjorn@tigerstaden.no>, "'Bill_de_hÓra'" <bill@dehora.net> Cc: "'Atom-Syntax'" <atom-syntax@imc.org> In-Reply-To: <000c01c48de7$084c81d0$6400a8c0@wyman.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Bob Wyman <bob@wyman.us> wrote: > > Asbjørn Ulsberg wrote: > > Should the acceptable [URI] schemes be enumerated > in the > > specification...? > Absolutely NO. Doing this would border on insanity. > > It is perfectly ok if the URI scheme used as an > "alternate" is > not supported by all clients. Heck, I can show you > clients that process > Atom feeds but don't support the http scheme! > Some clients know what to do with nntp:, news:, > http:, https:, > and even rtsp: and gopher:. The fact that all > clients won't know how to > handle every scheme is not a bug. Ignoring that this makes 'alternate' a bad name for the rel value how exactly does this not make interop worse? On the one hand, a feed author can decide that if they don't a website for the contens of the feed they can omit adding the link to the feed. This mean when users click 'Go to feed website' in the aggregator it reports back there is no website for the feed. This is a trivial check for me to add in RSS Bandit. On the other hand, feed authors are encouraged to arbitrary URI schemes such as mailto, nntp & news in there. The user clicks 'Go to feed website' and the user gets some ugly error message or at best a broken link. How is this making interop better? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Sun Aug 29 13:28:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21792 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 13:28:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THFe1A095316; Sun, 29 Aug 2004 10:15:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7THFeBs095315; Sun, 29 Aug 2004 10:15:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THFd9m095308 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:15:40 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so53971rnk for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:15:39 -0700 (PDT) Received: by 10.38.179.69 with SMTP id b69mr67095rnf; Sun, 29 Aug 2004 10:15:39 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sun, 29 Aug 2004 10:15:39 -0700 (PDT) Message-ID: <1f2ed5cd040829101554060c6b@mail.gmail.com> Date: Sun, 29 Aug 2004 19:15:39 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: Dare Obasanjo <kpako@yahoo.com> Subject: Re: URIs vs Strings Cc: Julian Reschke <julian.reschke@gmx.de>, asbjorn@tigerstaden.no, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <20040829105143.21819.qmail@web41215.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040829105143.21819.qmail@web41215.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Sun, 29 Aug 2004 03:51:43 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> wrote: > > --- Danny Ayers <danny.ayers@gmail.com> wrote: > > > > > > As long as consumers do what the spec says, > > canonicalization doesn't buy > > > you anything at all, as recipients compare as > > strings. > > > > Errm, yes it does, because there are loads of > > equivalent URIs > > comparisons that will produce false negatives if the > > consumer does > > string comparison, but that would match correctly if > > they were > > canonicalized before publication (and the consumer > > does string > > comparison). > > Instead of talking in hypotheticals can you actually > name some real life instances when this has actually > been a problem? You do realize that for the past five > years or more people have been exchanging XML > documents with URIs as identifiers [any RDF or XML > document with namespaces which includes 50% - 75% of > the RSS feeds in existence] over the Web and these > string comparison problems you claim will be an issue > have not been. Namespace identification is qualitively different from per-instance identification on the web. The requirements are different (a huge difference in the number of things identified), and there is considerably less experience to draw on. General good practice with identifiers suggests that ambiguity is best avoided, and URI canonicalization at source is a relatively low-cost way of minimizing ambiguity. > > Or it may lead to consumers thinking that producers > > all use string > > comparison, and get it wrong for those that don't. > > There's only a > > limited distance you can get in predicting > > non-compliant developer > > behaviour. I think we should guess on the side that > > favours doing the > > Right Thing. > > Basically you're trying to spec behavior for people > who won't read the spec? No. Because, like I said in the sentence before last, "There's only a limited distance you can get in predicting non-compliant developer behaviour.". So now producers have to do > extra, unnecessary work just in case some consumers > don't read the spec. No. Earlier in this thread you said: "However since this is the only issue holding up IDs I don't see why we can't just compromise on a SHOULD for canonicalizing URIs and move on.". I agree. > (a) That's the most ass backwards thing I've heard in > a while No. It's the most ass backwards thing you imagined you heard in a while. > (b) if the consumers are implemented incorrectly they > deserve the broken behavior that ensues I agree. But we should also make correct implementation as straightforward as possible. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Aug 29 13:30:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21899 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 13:30:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THOYT6095756; Sun, 29 Aug 2004 10:24:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7THOYqc095754; Sun, 29 Aug 2004 10:24:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THOX60095748 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:24:34 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7THOkgj004513; Sun, 29 Aug 2004 13:24:46 -0400 Message-ID: <41321155.8040606@intertwingly.net> Date: Sun, 29 Aug 2004 13:24:37 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: Atom-Syntax Syntax <atom-syntax@imc.org> Subject: Re: Feeds MUST have alternate links? References: <20040829170852.89804.qmail@web41202.mail.yahoo.com> In-Reply-To: <20040829170852.89804.qmail@web41202.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Sam Ruby <rubys@intertwingly.net> wrote: > >>>Please describe how interop is hurt by not having >>this >>>field instead of arguing by analogy. >> >>It was not my intent to argue by analogy. I thought >>I was clear: I was >>trying to explain the larger context in which I was >>looking at this >>issue. However, since I was less than successful >>the first time, let me >>try again: >> >>My overall thought process when modelling a syntax >>for interop loosely >>goes this: >> >>1) can this feature be REQUIRED? >>2) if not, can this feature be placed in an >>EXTENSION? >>3) if none of the above, then consider an OPTION. > > Interesting. I have totally different approach. Like > Anders Hejlsberg keeps telling us at work every > feature should start with a 1000 points against. Add 1 > for every good reason to have it, if you get to 0 then > ship the feature otherwise it isn't worth the cost. > It's a variation of "The hallmarks of a good design is > when you have nothing left to take out". It has been said that analogies are a weak way to debate. But based on this analogy with program products, I gather that your impression is that Anders would argue that the link element should be moved out of the core, and into an extension? Would this help or hurt interoperability? I don't know about you, but I find these word games tiring. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 13:41:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22643 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 13:41:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THVmgq096424; Sun, 29 Aug 2004 10:31:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7THVmpE096423; Sun, 29 Aug 2004 10:31:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7THVl4o096391 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:31:47 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829173146.13615.qmail@web41207.mail.yahoo.com> Received: from [24.18.132.80] by web41207.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 10:31:46 PDT Date: Sun, 29 Aug 2004 10:31:46 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: Feeds MUST have alternate links? To: Sam Ruby <rubys@intertwingly.net> Cc: Atom-Syntax Syntax <atom-syntax@imc.org> In-Reply-To: <41321155.8040606@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Sam Ruby <rubys@intertwingly.net> wrote: > > It has been said that analogies are a weak way to > debate. But based on > this analogy with program products, I gather that > your impression is > that Anders would argue that the link element should > be moved out of the > core, and into an extension? Would this help or > hurt interoperability? > > I don't know about you, but I find these word games > tiring. I asked you a question about feeds for USENET and mailing lists. I'd rather you answer that than trying to get into a debate over our different personal design styles since that is just a waste of everyone's time. You said the first question you ask yourself is "should it be required?" I was responding by letting you know that the first question I ask myself "should the feature exist?" I assume you felt there was some usefulness in explaining your personal design style and I was reciprocating so you know where I'm coming from. I doubt I'll change your mind on how you should approach Atom design and I don't think your going to change mine. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sun Aug 29 13:49:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22866 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 13:49:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THfow4097327; Sun, 29 Aug 2004 10:41:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7THfor4097326; Sun, 29 Aug 2004 10:41:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THfnml097314 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:41:49 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so54541rnk for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:41:47 -0700 (PDT) Received: by 10.38.179.69 with SMTP id b69mr73058rnf; Sun, 29 Aug 2004 10:41:47 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sun, 29 Aug 2004 10:41:47 -0700 (PDT) Message-ID: <1f2ed5cd04082910415ad2166d@mail.gmail.com> Date: Sun, 29 Aug 2004 19:41:47 +0200 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: Julian Reschke <julian.reschke@gmx.de> Subject: Re: atom:id - comparison and generation Cc: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>, "Bill de hÓra" <bill@dehora.net>, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <41320427.2050504@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4131E1B4.7040206@dehora.net> <opsdh306u4uvpchu@quark> <41320427.2050504@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Sun, 29 Aug 2004 18:28:23 +0200, Julian Reschke <julian.reschke@gmx.de> wrote: > -1. > > Reason: it makes the spec more complicated without having any effect > when clients indeed implement string comparison. There is a significant effect. For example, entries with the URIs : http://EXAMPLE.org/post1 and http://example.org/post1 will incorrectly show up as different if they aren't canonicalized before string comparison. This isn't a particularly forced example either, it's easy to imagine one publisher's convention being one form and a republishers being the other. So I say +1 to publishers/generators SHOULD canonicalize. Take your pick for comparison, SHOULD use char-by-char is probably the easiest for all concerned. Cheers, Danny. From owner-atom-syntax@mail.imc.org Sun Aug 29 14:11:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24342 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 14:11:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THwpTd098035; Sun, 29 Aug 2004 10:58:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7THwph0098034; Sun, 29 Aug 2004 10:58:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7THwogv098023 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 10:58:50 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id A94E87C1EE; Sun, 29 Aug 2004 20:49:00 +0200 (CEST) Date: Sun, 29 Aug 2004 19:59:39 +0200 To: bob@wyman.us Subject: Re: Feeds MUST have alternate links? Cc: Atom-Syntax <atom-syntax@imc.org> References: <000c01c48de7$084c81d0$6400a8c0@wyman.us> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <opsdh9lpdbuvpchu@quark> In-Reply-To: <000c01c48de7$084c81d0$6400a8c0@wyman.us> User-Agent: Opera M2/7.60 (Win32, build 7141) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On Sun, 29 Aug 2004 12:41:28 -0400, Bob Wyman <bob@wyman.us> wrote: >> Should the acceptable [URI] schemes be enumerated in the >> specification...? > > Absolutely NO. Doing this would border on insanity. I agree. Which is why <link rel="alternate"> should be optional. > It is perfectly ok if the URI scheme used as an "alternate" is > not supported by all clients. So <link rel="alternate" type="text/plain" href="data:My%20alternate%20content" /> is better than no <link> at all? > Heck, I can show you clients that process Atom feeds but don't > support the http scheme! Okay. My question still remains unanswered. Is it better with garbage content in <link> than no <link> at all? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Aug 29 14:15:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24706 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 14:15:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TI6eAI098253; Sun, 29 Aug 2004 11:06:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TI6e4r098252; Sun, 29 Aug 2004 11:06:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41211.mail.yahoo.com (web41211.mail.yahoo.com [66.218.93.44]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TI6e58098245 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 11:06:40 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829180638.38622.qmail@web41211.mail.yahoo.com> Received: from [24.18.132.80] by web41211.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 11:06:38 PDT Date: Sun, 29 Aug 2004 11:06:38 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: atom:id - comparison and generation To: Danny Ayers <danny.ayers@gmail.com>, Julian Reschke <julian.reschke@gmx.de> Cc: "Asbjørn" Ulsberg <asbjorn@tigerstaden.no>, Bill de "hÓra" <bill@dehora.net>, Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <1f2ed5cd04082910415ad2166d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Danny Ayers <danny.ayers@gmail.com> wrote: > > > http://EXAMPLE.org/post1 > and > http://example.org/post1 > > > This isn't a particularly forced example either, > it's easy to imagine > one publisher's convention being one form and a > republishers being the > other. Really? Then show me examples of where it has happened in the past. The examples I've seen in the wild based on customer reports in RSS Bandit are 1.) http://www.example.com/post1 and http://example.com/post1 AND 2.) http://www.example.com/GUID-uses-ABCDEF and http://www.example.com/guid-uses-abcdef Neither of which is helped by canonicalization. Canonicalization helps contrived edge cases while not applying to the actual problems that occur in the wild. However like I've said I see nothing wrong in telling people canonicalization is a good idea. Requiring it on the other hand... > So I say +1 to publishers/generators SHOULD > canonicalize. Take your > pick for comparison, SHOULD use char-by-char is > probably the easiest > for all concerned. Surely you mean MUST? Without a MUST requirement then comparison of IDs will be an interoperability fiasco. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Sun Aug 29 14:22:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25370 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 14:22:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TI9jH1098443; Sun, 29 Aug 2004 11:09:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TI9jVW098442; Sun, 29 Aug 2004 11:09:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TI9jp4098434 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 11:09:45 -0700 (PDT) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id i7TI9h420418 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 11:09:43 -0700 (PDT) Received: from aol.net ([10.169.192.22]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id I37ZS700.82L for <atom-syntax@imc.org>; Sun, 29 Aug 2004 11:09:43 -0700 Message-ID: <41321BEA.20105@aol.net> Date: Sun, 29 Aug 2004 11:09:46 -0700 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceProtocolDesignTeam2 revised References: <4131135A.70805@franklinmint.fm> <B1B85060-F979-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <B1B85060-F979-11D8-BAB9-000A95A51C9E@sun.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 28, 2004, at 4:20 PM, Robert Sayre wrote: > >> I've revised the Pace, removing any assertions about consensus. Note >> that debate on PUT/DELETE, etc. would be off-topic for the proposed >> design team list (but not atom-syntax). > > > This seems really counter-intuitive: the principal goal of having the > design team is to attract people to the discussion who care about > protocol issues but don't have time or patience to put up with our > endless torrents of verbiage about IDs and dates and so on. So, it > seems that the question of how best to use HTTP is one of the issues > that this kind of person will care about. I don't understand how > ruling it out of bounds is going to help. -Tim > I can understand why putting this out of bounds makes sense to give other issues a chance to see the light of day. But it doesn't make a lot of logical sense to someone new who hasn't been participating in the prior discussions, and I think we want to attract some of those people. Perhaps a rationale might help? Or perhaps this could be expressed as a conditional moratorium (until the following charter issues have consensus...) though that seems problematic too. -John From owner-atom-syntax@mail.imc.org Sun Aug 29 14:24:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25523 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 14:24:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TIEhMZ098654; Sun, 29 Aug 2004 11:14:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TIEhru098653; Sun, 29 Aug 2004 11:14:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TIEgOB098646 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 11:14:42 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 15805 invoked by uid 65534); 29 Aug 2004 18:14:40 -0000 Received: from pD9FF0984.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.9.132) by mail.gmx.net (mp005) with SMTP; 29 Aug 2004 20:14:40 +0200 X-Authenticated: #1915285 Message-ID: <41321D03.6070005@gmx.de> Date: Sun, 29 Aug 2004 20:14:27 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers <danny.ayers@gmail.com> CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>, =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: atom:id - comparison and generation References: <4131E1B4.7040206@dehora.net> <opsdh306u4uvpchu@quark> <41320427.2050504@gmx.de> <1f2ed5cd04082910415ad2166d@mail.gmail.com> In-Reply-To: <1f2ed5cd04082910415ad2166d@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Danny Ayers wrote: > On Sun, 29 Aug 2004 18:28:23 +0200, Julian Reschke > <julian.reschke@gmx.de> wrote: > > >>-1. >> >>Reason: it makes the spec more complicated without having any effect >>when clients indeed implement string comparison. > > > There is a significant effect. For example, entries with the URIs : > > http://EXAMPLE.org/post1 > and > http://example.org/post1 > > will incorrectly show up as different if they aren't canonicalized > before string comparison. Why are you saying "incorrectly"? If we spec string comparison, this is *exactly* what the producer should expect, it's easy to test and will quickly be discovered. > This isn't a particularly forced example either, it's easy to imagine > one publisher's convention being one form and a republishers being the > other. In which case the republisher broke the spec. Let's have good test cases, and this shouldn't be an issue. > So I say +1 to publishers/generators SHOULD canonicalize. Take your > pick for comparison, SHOULD use char-by-char is probably the easiest > for all concerned. Unless we make string comparison a MUST, I fail to see how IDs can work as expected. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sun Aug 29 14:47:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26951 for <atompub-archive@lists.ietf.org>; Sun, 29 Aug 2004 14:47:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TIeDBW000382; Sun, 29 Aug 2004 11:40:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TIeD1G000381; Sun, 29 Aug 2004 11:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from tara.bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TIeCJ2000375 for <atom-syntax@imc.org>; Sun, 29 Aug 2004 11:40:12 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from ken by tara.bitsko.slc.ut.us with local (Exim 4.34) id 1C1UaR-0004ui-EQ for atom-syntax@imc.org; Sun, 29 Aug 2004 13:39:31 -0500 To: atom-syntax@imc.org Subject: PaceContentAsTextOrHtml underspecified From: Ken MacLeod <ken@bitsko.slc.ut.us> Date: 29 Aug 2004 13:39:31 -0500 Message-ID: <87hdql23h8.fsf@bitsko.slc.ut.us> Lines: 70 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> -1 on PaceContentAsTextOrHtml, it is seriously underspecified. * Is the value of @type an Internet Media Type or is the value an enumeration of specific labels that are confusingly similar in appearance to Internet Media Types? * What is the difference between "text/plain" and "application/xhtml+xml" without an element wrapper, ie: <title type="text/plain">An ode to the <blink> tag An ode to the <blink> tag * What is the interpretation of these sequences of XML characters, based on @type: Line 1 Line 2 Line 1 Line 2 * Can the content of a content construct with type "text/html" include a complete HTML entity? For example: <![CDATA[<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> <TITLE>My first HTML document

Hello world! ]]> * Are two paragraphs in a title valid? For example: <p xmlns="http://www.w3.org/1999/xhtml">Paragraph 1</p> <p xmlns="http://www.w3.org/1999/xhtml">Paragraph 2</p> * What is the extensibility mechanism for content constructs? Can content from other XML namespaces be used as content values? Other media types? What is the default interpretation of unknown extension types? * Are or are not consumers expected to filter content for security and rendering purposes? Will any guidance be provided for publishers? * How is whitespace in general handled in "text/plain"? For example: This is some title * In "application/xhtml+xml", there are sequences of elements that are treated differently by current HTML renderers based on the ultimate XHTML document type delivered to the HTML renderer by the consumer. This should be noted. * XHTML 1.0, 1.1, or any? -- Ken From owner-atom-syntax@mail.imc.org Sun Aug 29 15:02:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27876 for ; Sun, 29 Aug 2004 15:02:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TIqHIE000984; Sun, 29 Aug 2004 11:52:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TIqHgr000983; Sun, 29 Aug 2004 11:52:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TIqGEJ000976 for ; Sun, 29 Aug 2004 11:52:16 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so105910rnb for ; Sun, 29 Aug 2004 11:52:14 -0700 (PDT) Received: by 10.38.179.69 with SMTP id b69mr97451rnf; Sun, 29 Aug 2004 11:51:56 -0700 (PDT) Received: by 10.38.179.23 with HTTP; Sun, 29 Aug 2004 11:51:56 -0700 (PDT) Message-ID: <1f2ed5cd04082911511f420285@mail.gmail.com> Date: Sun, 29 Aug 2004 20:51:56 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Julian Reschke Subject: Re: atom:id - comparison and generation Cc: "Asbjørn Ulsberg" , "Bill de hÓra" , Atom-Syntax In-Reply-To: <41321D03.6070005@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4131E1B4.7040206@dehora.net> <41320427.2050504@gmx.de> <1f2ed5cd04082910415ad2166d@mail.gmail.com> <41321D03.6070005@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 29 Aug 2004 20:14:27 +0200, Julian Reschke wrote: > Danny Ayers wrote: > > > On Sun, 29 Aug 2004 18:28:23 +0200, Julian Reschke > > wrote: > > > > > >>-1. > >> > >>Reason: it makes the spec more complicated without having any effect > >>when clients indeed implement string comparison. > > > > > > There is a significant effect. For example, entries with the URIs : > > > > http://EXAMPLE.org/post1 > > and > > http://example.org/post1 > > > > will incorrectly show up as different if they aren't canonicalized > > before string comparison. > > Why are you saying "incorrectly"? Because we're talking about URIs. They both identify the same resource according to rfc2396bis. If we spec string comparison, this is > *exactly* what the producer should expect, it's easy to test and will > quickly be discovered. ...and will be inconsistent with the rest of the web. > > This isn't a particularly forced example either, it's easy to imagine > > one publisher's convention being one form and a republishers being the > > other. > > In which case the republisher broke the spec. Let's have good test > cases, and this shouldn't be an issue. > > > So I say +1 to publishers/generators SHOULD canonicalize. Take your > > pick for comparison, SHOULD use char-by-char is probably the easiest > > for all concerned. > > Unless we make string comparison a MUST, I fail to see how IDs can work > as expected. Ok, sure, make it a MUST - Dare seems to like that too. Following the discussion surrounding client handling of ill-formed XML, I'm starting to suspect it's a waste of time trying to argue about spec'ing /anything/ for the consumer. The lowest common denominator holds all the aces. But all the more reason to try and get things right for the producers. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Aug 29 15:31:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00685 for ; Sun, 29 Aug 2004 15:31:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJKEsS002859; Sun, 29 Aug 2004 12:20:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TJKDE9002858; Sun, 29 Aug 2004 12:20:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJKDMw002848 for ; Sun, 29 Aug 2004 12:20:13 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7TJKH53026100 for ; Sun, 29 Aug 2004 13:20:17 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I38008B031SGB@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 29 Aug 2004 13:20:16 -0600 (MDT) Received: from [192.168.1.15] ([216.113.204.14]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I3800CHL31RE4@mail.sun.net> for atom-syntax@imc.org; Sun, 29 Aug 2004 13:20:16 -0600 (MDT) Date: Sun, 29 Aug 2004 12:20:15 -0700 From: Tim Bray Subject: Re: PaceProtocolDesignTeam2 revised In-reply-to: <4131698D.9060607@franklinmint.fm> To: Atom Syntax Message-id: <74E53A9A-F9F0-11D8-BAB9-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4131135A.70805@franklinmint.fm> <4131698D.9060607@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 28, 2004, at 10:28 PM, Robert Sayre wrote: > Many interested in the protocol have no tolerance for endless torrents > on PUT/DELETE vs. SOAP vs. custom headers. Hmm, you postulate the existence of a class of person who's interested in the Atom publishing protocol, but not about how it uses HTTP verbs, or whether it comprises a SOAP/WSDL module. This seems counter-intuitive. Having said that, I take Sam's point about wanting to focus on capabilities, and I agree. I just don't think that ruling the elephants in the room to be unmentionable is going to help progress. -Tim From owner-atom-syntax@mail.imc.org Sun Aug 29 15:38:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01079 for ; Sun, 29 Aug 2004 15:38:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJULFB003186; Sun, 29 Aug 2004 12:30:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TJULdR003185; Sun, 29 Aug 2004 12:30:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TJUKZB003177 for ; Sun, 29 Aug 2004 12:30:20 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail 10875 invoked by uid 65534); 29 Aug 2004 19:30:18 -0000 Received: from pD9FF0984.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.9.132) by mail.gmx.net (mp023) with SMTP; 29 Aug 2004 21:30:18 +0200 X-Authenticated: #1915285 Message-ID: <41322EC5.1090607@gmx.de> Date: Sun, 29 Aug 2004 21:30:13 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Atom-Syntax Subject: Re: atom:id - comparison and generation References: <4131E1B4.7040206@dehora.net> <41320427.2050504@gmx.de> <1f2ed5cd04082910415ad2166d@mail.gmail.com> <41321D03.6070005@gmx.de> <1f2ed5cd04082911511f420285@mail.gmail.com> In-Reply-To: <1f2ed5cd04082911511f420285@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: >>>On Sun, 29 Aug 2004 18:28:23 +0200, Julian Reschke >>> wrote: >>> >>> >>> >>>>-1. >>>> >>>>Reason: it makes the spec more complicated without having any effect >>>>when clients indeed implement string comparison. >>> >>> >>>There is a significant effect. For example, entries with the URIs : >>> >>>http://EXAMPLE.org/post1 >>>and >>>http://example.org/post1 >>> >>>will incorrectly show up as different if they aren't canonicalized >>>before string comparison. >> >>Why are you saying "incorrectly"? > > > Because we're talking about URIs. They both identify the same resource > according to rfc2396bis. No, we are talking about Atom IDs, which are strings taking the syntactical form of a URI. > If we spec string comparison, this is > >>*exactly* what the producer should expect, it's easy to test and will >>quickly be discovered. > > > ...and will be inconsistent with the rest of the web. Such as RDF and XML namespaces? > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sun Aug 29 15:40:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01300 for ; Sun, 29 Aug 2004 15:40:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJYxP7003355; Sun, 29 Aug 2004 12:34:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TJYxnb003354; Sun, 29 Aug 2004 12:34:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJYwFo003348 for ; Sun, 29 Aug 2004 12:34:59 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TJZBmE010273; Sun, 29 Aug 2004 15:35:11 -0400 Message-ID: <41322FE4.8050708@intertwingly.net> Date: Sun, 29 Aug 2004 15:35:00 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken MacLeod CC: atom-syntax@imc.org Subject: Re: PaceContentAsTextOrHtml underspecified References: <87hdql23h8.fsf@bitsko.slc.ut.us> In-Reply-To: <87hdql23h8.fsf@bitsko.slc.ut.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ken MacLeod wrote: > -1 on PaceContentAsTextOrHtml, it is seriously underspecified. > > * Is the value of @type an Internet Media Type or is the value an > enumeration of specific labels that are confusingly similar in > appearance to Internet Media Types? The latter. > * What is the difference between "text/plain" and > "application/xhtml+xml" without an element wrapper, ie: > > An ode to the <blink> tag > > An ode to the <blink> tag Text plain does not permit markup. This example does not include markup. > * What is the interpretation of these sequences of XML characters, > based on @type: > > > Line 1 > Line 2 > > > > Line 1 > Line 2 > For text/plain: http://www.w3.org/TR/2000/REC-xml-20001006#sec-white-space For text/html and application/xhtml+xml: http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1 > * Can the content of a content construct with type "text/html" > include a complete HTML entity? For example: > > <![CDATA[<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" > "http://www.w3.org/TR/html4/strict.dtd"> > <HTML> > <HEAD> > <TITLE>My first HTML document > > >

Hello world! > > > ]]> Good point. Only elements permitted inside html bodies was the intent. That was specified in application/xhtml+xml, but not in text/html. Thanks! > * Are two paragraphs in a title valid? For example: > > > <p xmlns="http://www.w3.org/1999/xhtml">Paragraph 1</p> > <p xmlns="http://www.w3.org/1999/xhtml">Paragraph 2</p> > Yes. > * What is the extensibility mechanism for content constructs? Can > content from other XML namespaces be used as content values? Other > media types? What is the default interpretation of unknown > extension types? No. From the first line of the abstract "Limit all such content to text/plain, text/html, and application/xhtml+xml." > * Are or are not consumers expected to filter content for security > and rendering purposes? Will any guidance be provided for > publishers? That would need to be covered by another pace. > * How is whitespace in general handled in "text/plain"? For example: > > This > is some title http://www.w3.org/TR/2000/REC-xml-20001006#sec-white-space > * In "application/xhtml+xml", there are sequences of elements that > are treated differently by current HTML renderers based on the > ultimate XHTML document type delivered to the HTML renderer by the > consumer. This should be noted. > > * XHTML 1.0, 1.1, or any? Any. > -- Ken - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 15:49:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01599 for ; Sun, 29 Aug 2004 15:49:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJg1PV003783; Sun, 29 Aug 2004 12:42:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TJg1HN003782; Sun, 29 Aug 2004 12:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJg0oF003771 for ; Sun, 29 Aug 2004 12:42:00 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i7TJgDlp010528; Sun, 29 Aug 2004 15:42:14 -0400 Message-ID: <4132318C.2030606@intertwingly.net> Date: Sun, 29 Aug 2004 15:42:04 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: PaceProtocolDesignTeam2 revised References: <4131135A.70805@franklinmint.fm> <4131698D.9060607@franklinmint.fm> <74E53A9A-F9F0-11D8-BAB9-000A95A51C9E@sun.com> In-Reply-To: <74E53A9A-F9F0-11D8-BAB9-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 28, 2004, at 10:28 PM, Robert Sayre wrote: > >> Many interested in the protocol have no tolerance for endless torrents >> on PUT/DELETE vs. SOAP vs. custom headers. > > Hmm, you postulate the existence of a class of person who's interested > in the Atom publishing protocol, but not about how it uses HTTP verbs, > or whether it comprises a SOAP/WSDL module. This seems counter-intuitive. > > Having said that, I take Sam's point about wanting to focus on > capabilities, and I agree. I just don't think that ruling the elephants > in the room to be unmentionable is going to help progress. -Tim At the moment, we aren't experiencing endless torrents on PUT/DELETE vs SOAP vs. custom headers, so I'm OK with not enacting a full prohibition on such topics until/unless they become a problem. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 29 15:55:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01797 for ; Sun, 29 Aug 2004 15:55:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJmC2N004187; Sun, 29 Aug 2004 12:48:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TJmC0m004186; Sun, 29 Aug 2004 12:48:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TJmBdP004180 for ; Sun, 29 Aug 2004 12:48:12 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 94716 messnum 4152299 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 29 Aug 2004 19:48:10 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail00.svc.cra.dublin.eircom.net (qp 94716) with SMTP; 29 Aug 2004 19:48:10 -0000 Message-ID: <413232F8.8050502@dehora.net> Date: Sun, 29 Aug 2004 20:48:08 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom-Syntax Subject: Re: Feeds MUST have alternate links? References: <20040829015916.94580.qmail@web41212.mail.yahoo.com> <41313D89.8030502@franklinmint.fm> <4131EBC4.5050003@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > On Sun, 29 Aug 2004 15:44:20 +0100, Bill de hÓra wrote: > >> I imagine it relies on the idea that a number of client readers embed >> browsers or browser components to render web content rather than code >> the rendering from scratch. > > > This is the machine-to-human use case of Atom. Maybe it is. > It also implies that > such browser widgets are available for the given platform and > environment. Shouldn't it be possible to create Atom user agents that > don't have a visual rendering API, like console applications, for > instance? Maybe. I was just thinking about an ability to switch on URI scheme. > Either way, there are a lot of compelling use cases for Atom that is > _not_ machine-to-human, but machine-to-machine. And even in many > machine-to-human scenarios, the humans really don't care about > alternative representations, as Arve told about his feed reading > statistics. > >> The browsers in question can switch based on the protocol. > > Not all of them can. I suppose those would be the browsers not in question. > How many support the NNTP scheme, for example? Or > NEWS, for that matter? What other schemes would be acceptable, and > which would not be? You're arguing with me as though I was adverse to your position. I'm not - you asked a question and I answered it. I'm not making any claims or objections beyond my answer. cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 29 15:55:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01849 for ; Sun, 29 Aug 2004 15:55:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJnaiY004285; Sun, 29 Aug 2004 12:49:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TJnaRR004284; Sun, 29 Aug 2004 12:49:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJnZ3P004276 for ; Sun, 29 Aug 2004 12:49:35 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7TJnZ6g007042; Sun, 29 Aug 2004 15:49:36 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BPC58270 (AUTH bob@wyman.us); Sun, 29 Aug 2004 15:49:34 -0400 (EDT) Message-Id: <200408291949.BPC58270@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: PaceContentSrc Date: Sun, 29 Aug 2004 15:47:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Thread-Index: AcSNfvY/ElL100KQQF6A5SHoMDHUMwAgZBtg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > +1 to optional content indirection. Note, since this suggests that > implementations would automatically retrieve resources from > heretofore unseen URIs that there is a security issue, and > should be noted in the spec. > > It should also be noted that there is a minor risk of DDOS attack here as well. If cients automatically retrieve indirect content, then one might publish a large number of indirect links in a popular feed in order to generate (number_of_links * number_of_readers) accesses to a remote, and presumably fragile, site. This is, of course, no different than many other similar opportunities on the web and should not, I think, be of distinct concern -- nonetheless, it should be mentioned. bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 29 16:04:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02256 for ; Sun, 29 Aug 2004 16:04:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJwqjO004725; Sun, 29 Aug 2004 12:58:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TJwqNI004724; Sun, 29 Aug 2004 12:58:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TJwpdo004718 for ; Sun, 29 Aug 2004 12:58:51 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 21730 messnum 5138166 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 29 Aug 2004 19:58:50 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail13.svc.cra.dublin.eircom.net (qp 21730) with SMTP; 29 Aug 2004 19:58:50 -0000 Message-ID: <41323578.9040407@dehora.net> Date: Sun, 29 Aug 2004 20:58:48 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Dare Obasanjo CC: Sam Ruby , Atom-Syntax Syntax Subject: Re: Feeds MUST have alternate links? References: <20040829173146.13615.qmail@web41207.mail.yahoo.com> In-Reply-To: <20040829173146.13615.qmail@web41207.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > --- Sam Ruby wrote: > >>It has been said that analogies are a weak way to >>debate. But based on >>this analogy with program products, I gather that >>your impression is >>that Anders would argue that the link element should >>be moved out of the >>core, and into an extension? Would this help or >>hurt interoperability? >> >>I don't know about you, but I find these word games >>tiring. > > > I asked you a question about feeds for USENET and > mailing lists. I'd rather you answer that than trying > to get into a debate over our different personal > design styles since that is just a waste of everyone's > time. Indeed, suddenly it's a waste of everyone's time. But you did care to point out someone else's style was not your design style and mention a design style not like it. But if you do feel it's a waste of my time, a response in kind is surely the wrong action. It's one to thing to point out argument from analogy is waste of time. It's another to be caught engaging in just that, and then make general objections in the direction of the person pointing it out instead of admitting it. cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 29 16:06:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02365 for ; Sun, 29 Aug 2004 16:06:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJup2g004621; Sun, 29 Aug 2004 12:56:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TJupKQ004620; Sun, 29 Aug 2004 12:56:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TJupiD004611 for ; Sun, 29 Aug 2004 12:56:51 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C1VnD-0005fG-VH; Sun, 29 Aug 2004 19:56:48 +0000 Message-ID: <41323503.5040104@franklinmint.fm> Date: Sun, 29 Aug 2004 15:56:51 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Tim Bray , Atom Syntax Subject: Re: PaceProtocolDesignTeam2 revised References: <4131135A.70805@franklinmint.fm> <4131698D.9060607@franklinmint.fm> <74E53A9A-F9F0-11D8-BAB9-000A95A51C9E@sun.com> <4132318C.2030606@intertwingly.net> In-Reply-To: <4132318C.2030606@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Tim Bray wrote: > >> >> On Aug 28, 2004, at 10:28 PM, Robert Sayre wrote: >> >>> Many interested in the protocol have no tolerance for endless >>> torrents on PUT/DELETE vs. SOAP vs. custom headers. >> >> >> Hmm, you postulate the existence of a class of person who's interested >> in the Atom publishing protocol, but not about how it uses HTTP verbs, >> or whether it comprises a SOAP/WSDL module. This seems >> counter-intuitive. I see a group of people who want to make sure the protocol works on J2ME, Flash, and some support for SOAP. I still see practically no voices that advocate getting rid of PUT and DELETE: http://www.imc.org/atom-syntax/mail-archive/msg09140.html >> >> Having said that, I take Sam's point about wanting to focus on >> capabilities, and I agree. I just don't think that ruling the >> elephants in the room to be unmentionable is going to help progress. > > > At the moment, we aren't experiencing endless torrents on PUT/DELETE vs > SOAP vs. custom headers, so I'm OK with not enacting a full prohibition > on such topics until/unless they become a problem. As long as reopening debate isn't *required*. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Aug 29 16:15:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02720 for ; Sun, 29 Aug 2004 16:15:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TK2JAV004848; Sun, 29 Aug 2004 13:02:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TK2JBI004847; Sun, 29 Aug 2004 13:02:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TK2IJT004841 for ; Sun, 29 Aug 2004 13:02:19 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 34360 messnum 5148407 invoked from network[83.70.37.85/83-70-37-85.bas2.prp.dublin.eircom.net]); 29 Aug 2004 20:02:17 -0000 Received: from 83-70-37-85.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.37.85) by mail13.svc.cra.dublin.eircom.net (qp 34360) with SMTP; 29 Aug 2004 20:02:17 -0000 Message-ID: <41323648.8000603@dehora.net> Date: Sun, 29 Aug 2004 21:02:16 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom-Syntax Subject: Re: atom:id - comparison and generation References: <4131E1B4.7040206@dehora.net> <41320427.2050504@gmx.de> In-Reply-To: <41320427.2050504@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > -1. > > Reason: it makes the spec more complicated without having any effect > when clients indeed implement string comparison. Julian, when you say complicated, do you mean it makes the spec more complicated for those generating IDs to implement in the absence of any benefit? cheers Bill From owner-atom-syntax@mail.imc.org Sun Aug 29 16:23:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03190 for ; Sun, 29 Aug 2004 16:23:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKEwIi005359; Sun, 29 Aug 2004 13:14:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TKEwK8005358; Sun, 29 Aug 2004 13:14:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKEv5e005350 for ; Sun, 29 Aug 2004 13:14:57 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7TKExvu013358; Sun, 29 Aug 2004 16:14:59 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BPC63300 (AUTH bob@wyman.us); Sun, 29 Aug 2004 16:14:57 -0400 (EDT) Message-Id: <200408292014.BPC63300@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Dare Obasanjo'" , , "'AsbjXrn_Ulsberg'" , "'Bill_de_hXra'" Cc: "'Atom-Syntax'" Subject: RE: Feeds MUST have alternate links? Date: Sun, 29 Aug 2004 16:13:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040829171428.71291.qmail@web41203.mail.yahoo.com> Thread-Index: AcSN67BtuG0+La1lRf6R6mc+ZdDzhAAFx5dw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > The user clicks 'Go to feed website' and the > user gets some ugly error message or at best a broken > link. How is this making interop better? Sounds like a poorly implemented client to me... Atom should or can only make interop promises concerning data which is in Atom format or about the mechanisms by which alternate data representations are addressed. Atom can no more require that all alternative representations be in some version of HTML that is universally understood (no such version exists) nor should it attempt to constrain all alternative formats to some known set. Atom goes far enough in providing a consistent mechanism for passing data in Atom format and for consistently encoding links to alternatives. I use Outlook Express as my NNTP News reader. Thus, when I click on a link to an NNTP newsgroup or to a specific NNTP message (identified with a "globally unique id"), Outlook Express is called and will open a window with either the newsgroup or the specific message in it. This is done with the assistance of Windows file associations, browser extensions, etc. Similar behavior, but with different tools, results if I click on an alternate which is gopher:, ftp:, etc. Atom does all it can be asked to do when it provides a consistent mechanism to address alternative content. It is up to the client developers to develop mechanisms to support a wide variety of alternatives. My guess is that those clients which support a wider variety of protocols will end up being more successful in the long run. The definition of Atom should not attempt to restrict this avenue for competitive differentiation. > This mean when users click 'Go to feed website' in the > aggregator it reports back there is no website for the > feed. This sounds like bad, inflexible, HTTP-centric client design. The UI should only say "go to website" if, in fact, the protocol in the URI is http or https. It would be improper to suggest that a newsgroup or entry in a newsgroup should be called a "website." > On the other hand, feed authors are encouraged > to arbitrary URI schemes such as mailto ... I would argue that "mailto" would not be an appropriate scheme for an "alternate" link since mailto is not used for retrieval but rather is used for addressing messages. This class of scheme should be prohibited from use in an "alternate" link since it can't be used to *retrieve* an alternate representation of the entry -- no matter how well the client is implemented. bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 29 16:27:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03373 for ; Sun, 29 Aug 2004 16:27:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKIkpo005521; Sun, 29 Aug 2004 13:18:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TKIkW3005520; Sun, 29 Aug 2004 13:18:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TKIjEf005510 for ; Sun, 29 Aug 2004 13:18:45 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829201845.17396.qmail@web41214.mail.yahoo.com> Received: from [24.18.132.80] by web41214.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 13:18:45 PDT Date: Sun, 29 Aug 2004 13:18:45 -0700 (PDT) From: Dare Obasanjo Subject: Re: Feeds MUST have alternate links? To: "Bill_de_hÓra" Cc: Sam Ruby , Atom-Syntax Syntax In-Reply-To: <41323578.9040407@dehora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Bill_de_hÓra wrote: > > Indeed, suddenly it's a waste of everyone's time. > But you did care > to point out someone else's style was not your > design style and > mention a design style not like it. But if you do > feel it's a waste > of my time, a response in kind is surely the wrong > action. > > It's one to thing to point out argument from analogy > is waste of > time. It's another to be caught engaging in just > that, and then make > general objections in the direction of the person > pointing it out > instead of admitting it. Why do you feel obligated to post some personal attack in every thread I am in? Did I owe you money in a past life or something? Besides getting in another snide personal attack what purpose does your response serve? Do you have any value to add to this thread besides indirect and passive-aggressive flaming? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-atom-syntax@mail.imc.org Sun Aug 29 16:36:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04073 for ; Sun, 29 Aug 2004 16:36:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKT0E8006192; Sun, 29 Aug 2004 13:29:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TKT0AJ006191; Sun, 29 Aug 2004 13:29:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7TKT0I7006185 for ; Sun, 29 Aug 2004 13:29:00 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20040829202859.22626.qmail@web41213.mail.yahoo.com> Received: from [24.18.132.80] by web41213.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 13:28:59 PDT Date: Sun, 29 Aug 2004 13:28:59 -0700 (PDT) From: Dare Obasanjo Subject: RE: Feeds MUST have alternate links? To: bob@wyman.us, "'AsbjXrn_Ulsberg'" , "'Bill_de_hXra'" Cc: "'Atom-Syntax'" In-Reply-To: <200408292014.BPC63300@ms8.netsolmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It seems we aren't start from the same basis. What is the purpose of alternate? The impression I've gotten from the few people who have piped to claim that it should be mandatory are basically users of what you have described as 'poorly implemented clients'. So if the feature is only useful to broken tools why are we even bothering to have it in Atom at all let alone debating whether it should be required or optional? By the way, no one has put forward a case for what should be done with when it comes to mailing lists. I notice the folks arguing that it should be required are either ignoring this question or have admitted there is no good value to put there. This already feels like a bad smell in the design for me. --- Bob Wyman wrote: > Dare Obasanjo wrote: > > The user clicks 'Go to feed website' and the > > user gets some ugly error message or at best a > broken > > link. How is this making interop better? > Sounds like a poorly implemented client to me... > Atom should or can only make interop promises > concerning data which > is in Atom format or about the mechanisms by which > alternate data > representations are addressed. Atom can no more > require that all alternative > representations be in some version of HTML that is > universally understood > (no such version exists) nor should it attempt to > constrain all alternative > formats to some known set. Atom goes far enough in > providing a consistent > mechanism for passing data in Atom format and for > consistently encoding > links to alternatives. > I use Outlook Express as my NNTP News reader. Thus, > when I click on > a link to an NNTP newsgroup or to a specific NNTP > message (identified with a > "globally unique id"), Outlook Express is called and > will open a window with > either the newsgroup or the specific message in it. > This is done with the > assistance of Windows file associations, browser > extensions, etc. Similar > behavior, but with different tools, results if I > click on an alternate which > is gopher:, ftp:, etc. > Atom does all it can be asked to do when it > provides a consistent > mechanism to address alternative content. It is up > to the client developers > to develop mechanisms to support a wide variety of > alternatives. My guess is > that those clients which support a wider variety of > protocols will end up > being more successful in the long run. The > definition of Atom should not > attempt to restrict this avenue for competitive > differentiation. > > > This mean when users click 'Go to feed website' in > the > > aggregator it reports back there is no website for > the > > feed. > This sounds like bad, inflexible, HTTP-centric > client design. The UI > should only say "go to website" if, in fact, the > protocol in the URI is http > or https. It would be improper to suggest that a > newsgroup or entry in a > newsgroup should be called a "website." > > > On the other hand, feed authors are encouraged > > to arbitrary URI schemes such as mailto ... > I would argue that "mailto" would not be an > appropriate scheme for > an "alternate" link since mailto is not used for > retrieval but rather is > used for addressing messages. This class of scheme > should be prohibited from > use in an "alternate" link since it can't be used to > *retrieve* an alternate > representation of the entry -- no matter how well > the client is implemented. > > bob wyman > > > ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sun Aug 29 16:46:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04669 for ; Sun, 29 Aug 2004 16:46:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKWmGI006590; Sun, 29 Aug 2004 13:32:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TKWmJr006589; Sun, 29 Aug 2004 13:32:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKWm1G006583 for ; Sun, 29 Aug 2004 13:32:48 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7TKWovu016072; Sun, 29 Aug 2004 16:32:51 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BPC66757 (AUTH bob@wyman.us); Sun, 29 Aug 2004 16:32:48 -0400 (EDT) Message-Id: <200408292032.BPC66757@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "=?iso-8859-1?Q?'Asbj=F8rn_Ulsberg'?=" Cc: "'Atom-Syntax'" Subject: RE: Feeds MUST have alternate links? Date: Sun, 29 Aug 2004 16:30:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Thread-Index: AcSN8dhflmupcOufR/2g6wDatBjdwwAE7V5Q Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7TKWm1G006584 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > So href="data:My%20alternate%20content" /> is better than no > at all? The example you gave does not conform to the requirements of the "data" URL scheme as documented in RFC2397. In order to conform to RFC2397 you would have to rewrite the href attribute as: Href="data:,My%20alternate%20content" The problem is that you left out the comma "," which is required syntax. See Section 4 of RFC2397[1] for a similar example. Nonetheless, as long as you pass the data in a manner which conforms to the data URI scheme, I don't see why it wouldn't be supported. Please note that "data" is only useful for small bits of data and is subject to processors' limitations on the length of URI's, etc. Also, please note that very few clients are likely to support this URI scheme. Thus, it would make sense for you to try your best to find an alternative alternate. > Okay. My question still remains unanswered. Is it better with garbage > content in than no at all? There should be no "garbage" content. Whatever is provided should be syntactically correct and have some meaning. At worst, point to a page that says that no alternate is available or that provides guidance on how to obtain alternates via mechanisms other than URI-dereferencing. bob wyman [1] http://www.ietf.org/rfc/rfc2397.txt From owner-atom-syntax@mail.imc.org Sun Aug 29 16:55:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05076 for ; Sun, 29 Aug 2004 16:55:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKl5Wq007417; Sun, 29 Aug 2004 13:47:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TKl5i8007416; Sun, 29 Aug 2004 13:47:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKl4fn007410 for ; Sun, 29 Aug 2004 13:47:05 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i7TKl8vu018048; Sun, 29 Aug 2004 16:47:08 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BPC69858 (AUTH bob@wyman.us); Sun, 29 Aug 2004 16:47:06 -0400 (EDT) Message-Id: <200408292047.BPC69858@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" , "'atom-syntax'" Subject: RE: atom:id - comparison and generation Date: Sun, 29 Aug 2004 16:45:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <4131E1B4.7040206@dehora.net> Thread-Index: AcSN0qyAzNTFRphNQe6sKMIWP388mQANfptg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > 1. Say generation SHOULD post-process to canonical form before emitting This would be acceptable but unfortunate. > 2. Say generation MUST post-process to canonical form before emitting +1. This would be best and does the most for interop. > 3. Say nothing about canonical forms for generation -1. This would be very bad. String comparision should be a MUST. bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 29 16:59:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05261 for ; Sun, 29 Aug 2004 16:59:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKqBaa008077; Sun, 29 Aug 2004 13:52:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TKqBx2008076; Sun, 29 Aug 2004 13:52:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from tara.bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TKqAds008062 for ; Sun, 29 Aug 2004 13:52:10 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from ken by tara.bitsko.slc.ut.us with local (Exim 4.34) id 1C1WeA-0005AI-5r for atom-syntax@imc.org; Sun, 29 Aug 2004 15:51:30 -0500 To: atom-syntax@imc.org Subject: Re: PaceContentAsTextOrHtml underspecified References: <87hdql23h8.fsf@bitsko.slc.ut.us> <41322FE4.8050708@intertwingly.net> From: Ken MacLeod Date: 29 Aug 2004 15:51:29 -0500 In-Reply-To: <41322FE4.8050708@intertwingly.net> Message-ID: <878ybx652m.fsf@bitsko.slc.ut.us> Lines: 49 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam Ruby writes: > Ken MacLeod wrote: > > * What is the interpretation of these sequences of XML characters, > > based on @type: > > > > Line 1 > > Line 2 > > > > > > Line 1 > > Line 2 > > > > For text/plain: http://www.w3.org/TR/2000/REC-xml-20001006#sec-white-space > > For text/html and application/xhtml+xml: > http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1 In the case of xml:space="default", should it be treated similarly to X/HTML characters? In the case of xml:space="preserve", should it be treated like multi-line, hard-breaking lines? The latter (xml:space="preserve") seems to contradict the Pace's rationale in that it is not "stuff that's already been proven to work and be interoperable". That's been my complaint with the label (or Internet Media Type) "text/plain" from early on: no RSS/Atom consumer implements "plain text" in a manner that is consistent with the use of "text/plain" in non-RSS/Atom tools. > > * Are two paragraphs in a title valid? For example: > > > > <p xmlns="http://www.w3.org/1999/xhtml">Paragraph 1</p> > > <p xmlns="http://www.w3.org/1999/xhtml">Paragraph 2</p> > > > > Yes. I would like to hear thoughts from implementors on this one. That seems like an invitation to not implement consistently or interoperably. This applies to both using block-level content with X/HTML and xml:space="preserve" with multi-line content. -- Ken From owner-atom-syntax@mail.imc.org Sun Aug 29 17:29:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06559 for ; Sun, 29 Aug 2004 17:29:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TLJ75W009346; Sun, 29 Aug 2004 14:19:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TLJ7Gb009345; Sun, 29 Aug 2004 14:19:07 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i7TLJ6OB009335 for ; Sun, 29 Aug 2004 14:19:07 -0700 (PDT) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id i7TLJ6q23035 for ; Sun, 29 Aug 2004 14:19:06 -0700 (PDT) Received: from aol.net ([10.169.192.22]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id I388JT01.Z31 for ; Sun, 29 Aug 2004 14:19:05 -0700 Message-ID: <4132484C.2080905@aol.net> Date: Sun, 29 Aug 2004 14:19:08 -0700 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: atom-syntax@imc.org Subject: Re: PaceContentAsTextOrHtml underspecified References: <87hdql23h8.fsf@bitsko.slc.ut.us> <41322FE4.8050708@intertwingly.net> In-Reply-To: <41322FE4.8050708@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Ken MacLeod wrote: > > ... > >> * Can the content of a content construct with type "text/html" >> include a complete HTML entity? ... > > Good point. Only elements permitted inside html bodies was the > intent. That was specified in application/xhtml+xml, but not in > text/html. Thanks! > 1. Does this rule out use of the inline HTML